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ABSTRACT 


This  thesis  reviews  the  Continuous  Acquisition  and  Life-cycle  Support  (CALS) 
initiative  and  its  data  format  specifications  and  analyzes  how  they  were  applied  to  the 
Evolved  SEASPARROW  Missile  (ESSM)  Program.  The  CALS  initiative  and  its  data 
format  specifications  were  developed  to  facilitate  management  of  defense  system  technical 
data.  With  recent  reforms  in  defense  acquisition  policy  called  for  in  Secretary  of  Defense 
memorandum,  “Specifications  &  Standards  -  A  New  Way  of  Doing  Business”  their 
application  to  defense  system  procurements  has  been  questioned. 

Following  a  review  of  the  CALS  initiative  and  its  data  format  specifications,  an 
analysis  of  the  application  of  the  CALS  initiative  to  the  ESSM  program  is  presented. 
Additionally,  the  information  technology  infrastructure  at  the  Navy’s  weapon  system  In- 
service  Support  Engineering  Agent  (ISEA),  Port  Hueneme  Division,  Naval  Surface 
Warfare  Center  is  presented,  and  analyzed  on  its  suitability  to  handle  CALS-compliant 
data  formats. 

This  research  concludes  that  the  CALS  initiative  and  its  data  format  specifications 
should  be  reviewed  as  to  their  application  to  the  Engineering  and  Manufacturing 
Development  phase  contract  of  the  ESSM  Program.  Furthermore,  this  research  concludes 
that  the  information  infrastructure  at  the  ISEA  is  not  fully  prepared  to  handle  technical 
data  in  CALS-compliant  data  formats.  Finally,  specific  recommendations  are  made  on 
how  the  Government  should  structure  its  Data  Management  Plan  to  convey  to  the  prime 
contractor  how  it  intends  to  manage  technical  data. 
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INTRODUCTION 


A.  BACKGROUND 

This  research  emanates  from  the  conflict  between  the  defense  acquisition 
manager’s  desire  for  delivery  of  weapon  system  technical  data  in  non-proprietary,  open 
formats  and  recent  changes  in  Department  of  Defense  (DoD)  acquisition  policy.  In  the 
past,  technical  data  such  as  engineering  drawings,  illustrations,  and  textual  data  for  a 
weapon  system  was  delivered  to  the  Government  in  paper  form.  This  made  it  necessary 
for  DoD  activities  involved  in  managing  the  acquisition  of  a  weapon  system  to  orient  their 
processes  around  handling  paper-based  documentation.  These  processes,  however,  were 
slow,  error-prone  and  manpower  intensive. 

In  the  mid  1980’s  the  DoD  sought  to  capitalize  on  advances  in  computer  hardware 
and  in  the  areas  of  computer-aided  design,  computer-aided  engineering,  and  concurrent 
engineering.  DoD  structured  a  series  of  military  specifications  and  standards  that 
facilitated  the  handling  of  weapon  system  technical  data  in  open,  digital  formats.  This 
initiative  grew  into  a  joint  DoD-industry  Continuous  Acquisition  and  Life-cycle  Support 
(CALS)  initiative  and  led  to  acquisition  processes  between  defense  contractors  and  DoD 
acquisition  managers  being  conducted  with  technical  data  in  digital  formats.  With  this 
change,  there  came  a  need  for  data  management  systems  that  could  receive,  store,  and 
manipulate  technical  data  in  its  various  formats.  Additionally,  many  of  the  acquisition 
management  processes  required  “reengineering”  using  concepts  such  as  Business  Process 
Reengineering  in  order  to  truly  reap  the  benefits  of  receiving,  handling,  and  managing 
technical  data  in  digital  formats. 

With  the  recent  changes  in  acquisition  policy  since  Secretary  of  Defense,  William  J. 
Perry’s  memorandum,  “Specifications  &  Standards  -  A  New  Way  of  Doing  Business,”  the 
application  of  the  CALS  initiative  and  its  data  format  specifications  to  DoD  weapon 
system  procurements  is  now  in  question.  Specifically,  Secretary  Perry  called  for  the  “use 
of  performance  and  commercial  specifications  and  standards  in  lieu  of  military 
specifications  and  standards,  unless  no  practical  alternative  exists  to  meet  the  user’s 
needs.”  (DoD  OSD,  1994,  pg.  1) 


1 


B.  THESIS  OBJECTIVES 


The  primary  objective  of  this  research  is  to  determine  whether  the  Continuous 
Acquisition  and  Life-cycle  Support  (CALS)  initiative  and  its  data  format  specifications 
should  have  been  applied  to  the  Engineering  and  Manufacturing  Development  (EMD) 
contract  for  the  Evolved  SEASP ARROW  Missile  (ESSM)  program.  To  achieve  this 
objective,  this  research  assesses:  (1)  the  CALS  initiative  strategies,  objectives  and  data 
format  specifications,  (2)  how  the  ESSM  program  office  applied  the  CALS  initiative  and 
their  data  format  specifications,  and  (3)  the  information  technology  (IT)  infrastructure  at 
the  Navy’s  weapon  system  In-service  Support  Engineering  Agent  (ISEA),  Port  Hueneme 
Division,  Naval  Surface  Warfare  Center  (PHD-NSWC). 

C.  RESEARCH  QUESTIONS 

This  thesis  attempts  to  answer  the  following  research  questions: 

1.  Primary  Research  Question 

Should  the  CALS  initiative  and  its  data  format  specifications  have  been  applied  to 
the  ESSM  program’s  EMD  phase  contract? 

2.  Secondary  Research  Questions 

•  Is  the  IT  infrastructure  at  the  ESSM  ISEA  adequate  to  support  the 
management  of  the  technical  data  for  the  Evolved  SEASP  ARROW  Missile 
during  the  life-cycle  of  the  weapon  system? 

•  How  could  the  ESSM  program  office  structure  the  Data  Management  Plan  for 
the  EMD  phase  contract  to  convey  to  the  prime  contractor  how  the 
Government  intends  to  manage  the  technical  data  associated  with  the  weapon 
system? 

D.  SCOPE  OF  THESIS 

This  thesis  analyzes  the  CALS  initiative  and  its  new  strategies  and  objectives  made 
public  in  October  1993.  It  also  presents  the  two  “flagship”  CALS  infrastructure 
modernization  systems  Joint  Computer-aided  Acquisition  and  Logistics  Support  (JCALS) 
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and  Joint  Engineering  Data  Management  Information  Control  System  (JEDMICS)  and 
analyzes  the  four  CALS  Data  Format  Specifications. 

The  Navy’s  ESSM  program’s  efforts  to  apply  the  CALS  initiative  and  its  data 
format  specifications  will  be  presented  through  the  acquisition  planning  and  source 
selection  phases  of  the  program.  This  thesis  does  not  address  how  the  ESSM  program 
intends  to  implement  the  CALS  initiative  during  management  of  the  ESSM  EMD  phase 
contract.  Instead,  it  offers  recommendations  on  how  the  Government  should  structure  its 
data  management  plan  to  ensure  complete  coverage  of  all  relevant  technical  data  issues 
with  the  prime  contractor. 

This  thesis  includes  an  analysis  of  the  information  technology  infrastructure  at  the 
Navy’s  ISEA  for  surface  ship  weapon  systems,  PHD-NSWC.  The  focus  is  on  whether 
PHD-NSWC  is  capable  of  performing  its  functions  as  the  ISEA  for  the  ESSM  if  the 
contractor-delivered  technical  data  is  in  CALS-compliant  technical  data  formats. 

E.  LITERATURE  REVIEW  AND  RESEARCH  METHODOLOGY 

The  research  on  the  CALS  initiative  is  primarily  a  review  and  analysis  of  CALS 
documents  that  have  been  issued  by  the  DoD  CALS  Policy  OflBce.  Department  of  Navy 
activities  that  have  responsibility  for  interpreting  the  CALS  initiative  and  providing 
implementation  guidance  on  the  initiative  for  Navy  and  Marine  Corps  activities  is  also 
reviewed  and  analyzed.  Additional  insight  into  how  the  CALS  initiative  and  its  principals 
are  being  implemented  in  defense  systems  by  the  U.S.  DoD,  foreign  DoDs,  and  by 
numerous  domestic  and  international  defense  contractors  was  gained  from  attendance  at 
the  seventh  annual  CALS  Conference  and  Exposition  December  7-9,  1994  in  Long  Beach, 
CA.  The  information  on  the  ESSM  Program  is  drawn  from  documentation  on  the 
program  provided  by  PHD-NSWC  and  from  interviews  with  PHD-NSWC’ s  ISEA 
representative  for  ESSM.  The  analysis  of  the  IT  infi-astructure  at  PHD-NSWC  was 
obtained  during  three  separate  visits  to  Port  Hueneme.  It  is  based  on  open  observation  of 
the  work  environment  at  PHD-NSWC,  direct  interaction  with  the  Joint  Computer-aided 
Acquisition  and  Logistic  Support  (JCALS)  system,  and  observation  of  the  Integrated  Data 
Management  System  (IDMS)  during  a  demonstration. 
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F.  CHAPTER  OVERVIEWS 

This  thesis  is  organized  in  six  chapters.  The  following  is  an  overview  of  the 
remaining  chapters. 

Chapter  II,  “Continuous  Acquisition  and  Life-cycle  Support  Initiative,”  presents 
this  joint  DoD-industry  initiative  and  the  two  implementations  under  its  infrastructure 
modernization  strategy.  Chapter  III,  “CALS  Data  Format  Specifications,”  describes  the 
four  data  format  specifications  that  have  been  created  under  the  CALS  initiative.  Chapter 
IV,  “Evolved  SEASPARROW  Missile  Program,”  presents  an  overview  of  the  Navy’s 
plans  to  acquire  an  upgrade  to  the  RIM-7P  surface-to-air  missile.  Chapter  V, 
“Information  Technology  Infrastructure  at  the  In-service  Support  Engineering  Agent,” 
describes  PHD-NSWC’s  current  technical  data  management  system  and  plans  to  integrate 
that  system  with  portions  of  the  JCALS  system.  Finally,  Chapter  VI,  “Conclusions  and 
Recommendations  for  the  Management  of  Technical  Data  for  the  ESSM  Program,” 
presents  several  conclusions  drawn  from  this  research  and  discusses  issues  requiring 
further  research.  This  chapter  also  offers  recommendations  on  how  issues  related  to  the 
management  of  ESSM  technical  data  should  be  described  by  the  Government  to  potential 
contractors. 

G.  ACRONYMS 

This  thesis  contains  numerous  acronyms  throughout  each  of  the  chapters.  Listed 
below  are  some  of  the  most  frequently  used  acronyms; 


CALS 

Continuous  Acquisition  and  Life-cycle  Support 

CDRL 

Contract  Data  Requirements  List 

CGM 

Computer  Graphics  Metafile 

CITIS 

Contractor  Integrated  Technical  Information  Services 

COTS 

Commercial  Off-The-Shelf 

DMP 

Data  Management  Plan 

DoD 

Department  of  Defense 

DoN 

Department  of  the  Navy 

EMD 

Engineering  and  Manufacturing  Development 

ESSM 

Evolved  SEASPARROW  Missile 
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GCO 

Government  Concept  of  Operations 

GFI 

Government  Furnished  Information 

GOTS 

Government-Owned  Software 

IDMS 

Integrated  Data  Management  System 

IGES 

Initial  Graphics  Exchange  Specification 

ISEA 

In-service  Support  Engineering  Agent 

IT 

Information  Technology 

JCALS 

Joint  Computer-aided  Acquisition  and  Logistics  Support 

JEDMICS 

Joint  Engineering  Data  Management  Information  Control 
System 

MAPP 

Master  Program  Plan 

NAVSEA 

Naval  Sea  Systems  Command 

PHD-NSWC 

Port  Hueneme  Division,  Naval  Surface  Warfare  Center 

PM 

Program  Manager 

RFC 

Request  For  Comment 

RFP 

Request  For  Proposal 

SGML 

Standard  Generalized  Markup  Language 

SoW 

Statement  of  Work 
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II.  CONTINUOUS  ACQUISITION  AND  LIFE-CYCLE  SUPPORT  (CALS) 

INITIATIVE 

This  chapter  begins  by  providing  background  information  on  the  CALS  initiative 
and  then  describes  the  current  DoD  CALS  strategic  goals.  Next,  organizations  affiliated 
with  CALS  and  the  documentation  associated  with  CALS  are  presented.  These  are 
followed  by  the  CALS  implementation  strategies  and  acquisition  process  guidance.  This 
chapter  concludes  with  descriptions  of  the  two  “flagship”  CALS  initiative 
implementations:  the  Joint  Continuous  Acquisition  and  Logistics  Support  (JCALS) 
program  and  the  Joint  Engineering  Data  Management  Information  Control  System 
(JEDMICS). 

A.  BACKGROUND 

This  background  information  is  taken  from  Annex  1  of  the  CALS  Strategic  Plan 
published  by  the  DoD  CALS  &  EDI  (Electronic  Data  Interchange)  Office  in  October 
1993. 


1.  CALS  Origins 

In  the  mid  1980’s,  the  DoD  instituted  the  Computer-Aided  Logistics  Support 
(CALS)  initiative  as  an  effort  to  standardize  how  technical  information  should  be  managed 
within  the  department.  Advances  in  computer-aided  design,  computer-aided 
manufacturing  and  computer-aided  engineering  led  defense  logisticians  to  move  away 
from  a  paper-based  technical  documentation  system  to  a  system  where  technical 
information  is  created,  managed  and  distributed  in  digital  forms.  It  was  thought  that  the 
CALS  initiative  could  help  the  DoD  reduce  its  costs  for  acquiring  technical  documentation 
while  making  it  more  accurate,  current  and  timely.  In  its  beginnings,  CALS  primarily  dealt 
with  the  logistics  of  support  documentation. 

2.  CALS  Evolution 

As  the  benefits  of  the  CALS  initiative  became  better  known,  DoD  acquisition 
managers  sought  to  incorporate  CALS  concepts  into  weapon  systems  procurements.  In 
1988,  CALS  was  renamed  the  Computer-aided  Acquisition  and  Logistics  Support 
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initiative.  This  better  reflected  its  use  in  managing  the  technical  information  associated 
with  weapon  system  acquisition. 

Developments  in  the  field  of  Concurrent  Engineering  (CE)  eventually  led  the 
CALS  initiative  to  encompass  all  aspects  of  weapon  system  acquisition;  design, 
production  and  logistics  support  processes.  Similarly,  advances  in  telecommunications 
such  as  enterprise  networking  and  digital  information  exchange  protocols  led  to  more 
technical  documentation  to  be  exchanged  between  businesses.  Terms  such  as  electronic 
commerce  and  electronic  data  interchange  soon  became  associated  with  CALS. 

3.  CALS  Today 

Now  renamed  Continuous  Acquisition  and  Life-cycle  Support,  the  CALS  initiative 
has  been  expanded  from  its  roots  in  technical  documentation  and  logistics  support  to  CE 
and  integrated  business  processes.  It  has  gained  acceptance  outside  the  DoD  and  defense 
industries  to  become  a  joint  DoD-industry  managed  initiative.  The  CALS  initiative  has 
also  been  accepted  and  implemented  within  international  defense  departments  in  Canada, 
Europe,  Asia,  and  Australia. 

4.  CALS  Vision 

The  CALS  Industry  Steering  Group  has  promulgated  a  vision  statement  that  is 
quoted  below.  It  was  taken  from  the  conference  guide  to  the  seventh  annual  “CALS  Expo 
94  International”  Conference  and  Exposition. 

The  Vision  is  for  all  or  part  of  a  single  enterprise  (e  g.,  an  original 
equipment  manufacturer  and  its  suppliers,  or  a  consortium  of  public  and 
private  groups  and  academia),  to  be  able  to  work  from  a  common  digital 
data  base,  in  real  time,  on  the  design,  development,  manufacturing, 
distribution  and  ser\dcing  of  products.  The  direct  benefits  would  come 
through  substantial  reductions  in  product-to-market  time  and  costs,  along 
with  significant  enhancements  in  quality  and  performance. 

B.  STRATEGIC  GOALS  AND  OBJECTIVES 

The  strategic  plan  is  intended  to  expand  upon  the  CALS  Vision.  Each  of  the  three 
strategic  goals  and  their  supporting  objectives  is  quoted  below  in  italicized  text  and  is 
elaborated  upon  in  plain  text. 
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1. 


Strategic  Goal  1 


Expand  DoD  ’5  relationship  with  industry  to  adopt  more  harmonious  methods  of 
operation  and  data  exchange.  This  goal  describes  the  DoD’s  desire  to  work  more  closely 
with  our  nation’s  defense  industrial  base  for  weapon  system  procurements.  In  the  past  the 
DoD  has  relied  heavily  on  military  specifications  and  standards  to  direct  contractors  on 
how  to  deliver  a  product.  With  reduced  levels  of  funding  for  defense  acquisitions  today, 
the  DoD  is  seeking  to  substitute  commercial  equivalents  for  military  needs  whenever 
possible.  This  change  places  more  trust  on  our  defense  industrial  base  to  recommend 
industry  standards  in  response  to  Requests  For  Comments  (RFCs)  and  Requests  For 
Proposals  (RFPs). 

a.  Objective  lA 

Develop  a  DoD  and  industry  infostructure.  Development  of  a  common 
means  of  exchanging  digital  information  between  the  DoD  and  industry  is  intended  to 
integrate  combat  units  with  the  defense  industry.  The  architecture  for  this  capability  is 
being  developed  in  concert  vrith  Command,  Control,  Communications,  and  Intelligence 
(C3I)  planners  within  the  Pentagon. 

b.  Objective  IB 

Enable  “dual  use  ”  technologies.  “Dual  use”  technologies  refer  to  industry 
or  commercial  products  that  fulfill  military  needs.  The  hope  is  that  innovative  commercial 
products  will  be  delivered  to  combat  forces  more  rapidly  and  at  a  lower  cost  to  the  DoD. 

c.  Objective  1C 

Harmonize  standards  and  practices.  When  the  DoD  feels  the  need  to 
publish  a  military  specification  or  standard,  it  currently  submits  it  to  industry  groups  and 
national  and  international  standards  organizations  for  comments.  The  goal  is  to  have  all 
possible  military  specifications  and  standards  relating  to  information  technology  migrate  to 
Federal  Information  Processing  Standards  (FIPS)  or  international  standards  in  the  fixture. 
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d.  Objective  ID 

Provide  CALS  expertise  through  education  and  training.  The  Defense 
CALS  Executive  is  tasked  to  provide  CALS  implementation  guidance  for  users  and 
industry  alike.  Federal  agencies  such  as  the  Department  of  Commerce  (DoC)  and  the 
Advance  Research  Projects  Agency  (ARP A)  are  to  assist  the  DoD  in  developing  CALS 
curricula  for  entities  such  as  small  business  defense  contractors  and  academia. 

2.  Strategic  Goal  2 

Complete  the  transition  of  DoD 's  active  information  and  business  transactions  to 
standard  electronic  formats.  This  goal  describes  the  need  for  the  DoD  to  abandon  paper- 
based  systems  for  technical  documentation  and  logistics  support  in  favor  of  digital  data 
formats.  Documentation  required  for  the  management  of  weapon  systems  acquisitions 
should  be  digitally  encoded  and  simultaneously  available  to  the  DoD  Program  Executive 
Office  and  the  defense  primary  and  sub  contractors. 

a.  Objective  2A 

Modernize  DoD  hardware  and  software.  This  objective  describes  the 
transition  from  filing  cabinets  in  DoD  offices  to  computer  workstations  on  every  desk.  As 
hardware  and  software  is  purchased  for  CALS-compliant  purposes,  adherence  to  open 
standards  is  mandatory. 

b.  Objective  2B 

Acquire  new  data  in  digital  form.  Acquisition  of  new  data  in  digital  form 
requires  the  procuring  military  department  or  agency  to  have  procedures  in  place  for 
handling  the  digital  data.  Existing  procedures  for  the  handling  of  paper-based 
documentation  will  be  insufficient  for  the  manipulation  and  management  of  data  in  digital 
formats;  these  procedures  must  be  reconsidered. 

c.  Objective  2C 

Convert  existing  data  to  digital  form.  Paper-based  legacy  data  must  be 
evaluated  for  the  cost  effectiveness  of  its  conversion  to  digital  form.  For  weapon  systems 
expected  to  remain  in  the  inventory  for  years  to  come,  conversion  of  their  documentation 
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to  digital  formats  must  be  done  with  an  eye  toward  which  digital  formats  are  most  widely 
accepted  and  most  robust  for  future  needs. 

d.  Objective  2D 

Conduct  business  transactions  in  digital  form.  This  objective  is  directed 
toward  conducting  defense  acquisitions  within  the  guidelines  of  Electronic  Commerce 
(EC)  using  Electronic  Data  Interchange  (EDI)  standards.  It  is  anticipated  that  this 
objective  will  lead  to  quicker  turn-arounds  on  management  decisions  for  acquisition 
managers. 

3.  Strategic  Goal  3 

Continue  progress  toward  integration  of  DoD 's  digital  information.  This  goal 
addresses  the  need  for  the  DoD  to  be  able  to  digitally  share  all  information  concerned  with 
a  weapon  system  \vith  acquisition  managers,  contractors,  logistics  support  personnel  and 
end-users.  The  intent  is  to  develop  an  Integrated  Weapon  System  Data  Base  (IWSDB)  as 
the  repository  for  all  data  elements  of  a  particular  weapon  system.  Much  fundamental 
research  must  be  conducted  to  develop  a  data  model,  proper  access  restrictions  and 
security  protections  for  such  a  data  base. 

a.  Objective  3A 

Develop  an  integrated  infostructure.  This  objective  calls  for  the 
development  of  a  standard  for  digital  information  exchange.  Without  efficient  information 
sharing,  management  of  business  processes  cannot  effectively  begin.  The  DoD  is  actively 
working  with  industry  and  national  and  international  standards  organizations  to  develop  a 
digital  information  exchange  standard  that  will  adequately  handle  the  requirements  for  a 
system  that  is  expected  to  have  a  long  life-cycle. 

b.  Objective  3B 

Align  defense  integrated  infostructure  with  the  national  information 
infrastructure.  The  National  Information  Infrastructure  (Nil)  or  “information 
superhighway”  is  in  the  conceptual  stages  with  various  federal  agencies  and  the  private 
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sector.  The  DoD  must  remain  cognizant  of  the  progress  in  defining  the  Nil  so  that  it  may 
seamlessly  integrate  with  it  should  the  need  arise  in  the  future. 

c.  Objective  3C 

Promote  business  process  reengineering.  Business  Process  Reengineering 
(BPR)  was  first  introduced  to  the  DoD  in  the  Corporate  Information  Management  (CIM) 
initiative  in  the  late  1980’s.  As  the  DoD  attempts  to  move  away  from  managing  paper- 
based  systems  to  managing  information  digitally,  it  must  avoid  the  urge  to  simply 
automate  what  perhaps  is  a  bad  process  through  the  application  of  computer  technology. 
Much  effort  must  be  conducted  in  the  fields  of  workflow  management,  workgroup 
computing  and  business  process  reengineering  to  ensure  that  DoD  agencies  and  military 
departments  are  prepared  for  the  new  ways  of  managing  information. 

C.  CALS  ORGANIZATIONS 

This  section  describes  the  various  government,  industry  and  international 
organizations  that  participate  in  the  CALS  initiative. 

1.  Government 

a.  Department  of  Defense 

Within  the  Department  of  Defense  (DoD),  the  CALS  initiative  is  managed 
by  the  CALS  &  EDI  Office  within  the  Office  for  the  Under  Secretary  of  Defense 
(Acquisition  and  Technology).  This  office  is  responsible  for  issuing  CALS  directives  and 
coordinating  CALS  efforts  among  DoD  military  departments  and  agencies.  The  CALS  & 
EDI  Office  is  the  point-of-contact  for  CALS  issues  when  interacting  with  other  federal 
agencies. 

The  Defense  Information  Systems  Agency  (DISA)  Information  Processing 
Directorate  maintains  the  Center  for  Standards  (CFS)  as  the  DoD’s  repository  for 
information  processing  standards.  The  CFS  is  authorized  and  responsible  for  adopting, 
developing,  specifying,  certifying  and  enforcing  information  processing  standards  for  the 
DoD. 
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b.  Department  of  the  Navy 


Each  military  department  has  a  representative  within  the  CALS  and  EDI 
Office  and  uses  smaller  entities  to  manage  the  CALS  initiative.  Within  the  Department  of 
the  Navy  (DoN),  the  Naval  Air  Warfare  Center,  Naval  Surface  Warfare  Center  and  Naval 
Undersea  Warfare  Center  all  have  divisions  that  participate  in  the  CALS  initiative  to 
varying  degrees.  The  Carderock  Division  of  the  Naval  Surface  Warfare  Center  is  the 
repository  for  CALS  standards  and  the  lead  testbed  for  the  CALS  Test  Network  within 
the  DoN. 

The  Naval  Air  Warfare  Center,  Aircraft  Division,  Indianapolis,  IN  and  the 
Naval  Surface  Warfare  Center,  Crane  Division,  Louisville,  KY  and  Crane,  IN 
cooperatively  maintain  the  CALS  Resource  and  Implementation  Cooperative  (RIC).  The 
RIC  was  established  as  the  primary  source  for  technical  guidance  for  naval  forces 
attempting  to  implement  or  apply  the  CALS  initiative. 

c.  Federal  Agencies 

Besides  the  DoD,  other  federal  agencies,  such  as  the  Department  of 
Commerce  (DoC)  and  the  Advance  Research  Projects  Agency  (ARP A)  have  roles  and 
responsibilities  in  the  CALS  initiative. 

The  National  Institute  of  Standards  and  Technology  (NIST),  a  part  of  the 
DoC,  has  been  tasked  to  provide  the  DoD  assistance  in  developing  the  CALS  standards. 
NIST  works  with  military  departments  and  agencies,  industry  and  national  and 
international  standards  organizations  to  develop  the  CALS  initiative  standards  and  to 
make  recommendations  to  the  CALS  and  EDI  Office  on  which  standards  to  implement. 
Additionally,  NIST  through  the  Manufacturing  Extension  Partnership  maintains  thirty-six 
Manufacturing  Extension  Centers  that  help  small-to-medium-sized  manufacturers  increase 
their  international  competitiveness.  (Snodgrass,  1994,  pg.  13) 

The  DoC’s  National  Technical  Information  Service  (NTIS)  is  the  central 
repository  for  over  1,000  CALS  documents.  These  documents  are  available  through  File 
Transfer  Protocol  (FTP)  at  Internet  host  address  192.239.92.203,  by  modem  on 
FedWorld  Bulletin  Board  System  (BBS)  at  1-703-321-8020  and  voice  telephone  at  1-703- 
487-4823  (information)  and  1-703-487-4650  (ordering). 
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ARPA  manages  the  Electronic  Commerce  Resource  Centers  (ECRC)  ^ 
which  assist  small  manufacturers  with  CALS  concepts  and  strategy  by  providing  education 
and  training.  The  ECRC  will  go  as  far  as  to  visit  manufacturers  and  conduct  business-case 
analysis  to  determine  return  on  investment  on  implementing  CALS  concepts.  (Snodgrass, 
1994,  pg.  13) 

2.  Industry 

The  CALS  initiative  being  a  joint  DoD-industry  program,  is  primarily  represented 
by  the  CALS  Industry  Steering  Group  (ISG).  The  CALS  ISG  leadership  has  recently 
renamed  the  CALS  initiative  to  Commerce  at  Light  Speed  to  better  reflect  the  ISG’s 
opinion  that  CALS  strengths  rest  with  Enterprise  Integration  (El)  efforts  in 
manufacturing.  (Snodgrass,  1994,  pg.  II) 

The  CALS  ISG  has  formed  Regional  Interest  Groups  (RIGs)  to  meet  periodically 
with  industry  representatives  to  keep  them  current  with  the  latest  CALS  developments. 
At  the  time  of  this  writing  there  are  CALS  RIGs  in  at  least  25  states.  (Snodgrass,  1994, 
pg-  13) 

For  the  purposes  of  providing  individuals  the  opportunity  to  comment  on  CALS 
standards  and  specifications,  the  CALS  ISG  maintains  a  BBS.  This  BBS  serves  as  a 
means  for  distributing  of  CALS  documents  and  as  a  forum  for  submitting  comments  on 
proposed  standards  and  specifications.  The  number  for  the  BBS  is  1-703-321-8020  for 
modem  access.  (Smith  and  Ellis,  1994,  pg.  10) 

3.  International 

At  the  seventh  aimual  CALS  conference  and  exposition  on  December  6,  1994,  the 
CALS  ISG  Executive  Advisory  Council  announced  the  formation  of  CALS  International. 
CALS  International  will  serve  to  advance  international  business  by  promoting  the  use  of 
standards  and  shared  digital  data  in  electronic  commerce.  Presently,  there  are  nine  nations 
with  CALS  ISG  organizations:  United  States,  Canada,  United  Kingdom,  France, 
Germany,  Sweden,  Japan,  Taiwan,  and  Australia.  Additional  countries  are  expected  to 
formalize  a  CALS  organization  with  the  announcement  of  CALS  International. 


^  These  centers  were  formerly  know'n  as  CALS  Shared  Resource  Centers  (CSRC). 
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The  CALS  International  will  consist  of  three  elements: 

•  An  International  Board  of  Directors,  responsible  for  setting  priorities,  defining 
long-range  objectives  and  forging  strategic  partnerships  and  cooperative 
relationships; 

•  The  International  CALS  Congress,  responsible  for  developing  a  coordinated 
approach  to  implementing  CALS  requirements;  and 

•  The  International  CALS  Secretariat,  responsible  for  providing  staff  support. 

D.  CALS  DIRECTIVES,  GUIDANCE  AND  STANDARDS 

This  section  will  describe  the  documentation  associated  with  the  CALS  initiative. 

1.  Directives 

Usage  of  CALS  for  the  acquisition  of  new  weapon  systems  and  major  equipment 
was  first  mandated  in  August  1988  by  the  Deputy  Secretary  of  Defense  in  a  memorandum 
to  military  department  secretaries  and  the  director  of  the  Defense  Logistics  Agency. 
Citing  that  “CALS  standards  will  enable  either  digital  data  delivery  or  government  access 
to  contractor-mmntained  technical  data  bases,”  CALS  standards  were  specified  for  two 
types  of  acquisition  scenarios: 

•  For  systems  now  in  full-scale  development  or  production,  program  managers 
shdl  review  specific  opportunities  for  cost  savings  or  quality  improvements 
that  could  result  from  changing  weapon  system  paper  deliverables  to  digital 
delivery  or  access  using  the  CALS  standards. 

•  For  systems  entering  development  after  September  1988,  acquisition  plans, 
solicitations,  and  related  documents  should  require  specific  schedule  and  cost 
proposals  for:  (1)  Integration  of  contractor  technical  information  systems  and 
processes;  (2)  Authorized  government  access  to  contractor  data  bases;  (3) 
Delivery  of  technical  information  in  digital  form. 

This  memorandum  (since  canceled)  was  later  codified  in  the  Defense  Federal 
Acquisition  Regulation  Supplement  (DFARS).  DFARS  tasks  acquisition  managers  and 
program  offices  for  planned  acquisitions  to: 
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•  Implement  CALS  standards  in  new  defense  system  acquisitions  with  CALS 
requirements  being  incorporated  in  the  Requests  For  Proposals  (RFPs)  and 
eventually  the  contracts; 

•  Describe  the  extent  of  how  the  CALS  standards  have  been  implemented  in 
their  acquisition  planning; 

•  Ensure  that  their  offices  have  the  sufficient  computer  technology  infrastructure 
in  place  and  are  capable  of  receiving  and  managing  digital  data. 

For  weapon  systems  already  in  the  DoD  inventory,  DFARS  requires  managers  to 
“exploit”  the  CALS  standards  by  converting  existing  paper-based  technical  data  to  digital 
data.  This  requirement  is  made  with  the  understanding  that  the  program’s  phase,  type, 
size  and  duration  should  be  the  overriding  consideration  before  proceeding  with  any 
conversion. 

Two  other  directives  relating  to  the  CALS  initiative,  both  titled  Computer-aided 
Acquisition  and  Logistics  Support,  include  OPNAVTNST  4120.5,  dated  I  July  1992  and 
SECNAVINST  5000.2A,  dated  9  December  1992  with  Change  1  dated  26  February  1993. 
The  Defense  Acquisition  Board,  Logistics  Review  Groups,  Major  Automated  Information 
System  Review  Council,  and  other  unspecified  oversight  activities  are  tasked  by  the 
DFARS  to  review  and  audit  defense  acquisition  managers  for  compliance  with  DoD  and 
DoD  component  CALS  policy. 

On  June  29,  1994,  Secretary  of  Defense  William  J.  Perry  issued  a  memorandum  to 
the  Secretaries  of  the  Military  Departments  and  the  Directors  of  the  Defense  Agencies 
directing  that  “performance  specifications  shall  be  used  when  purchasing  new  systems, 
major  modifications,  upgrades  to  current  systems,  and  nondevelopmental  and  commercial 
items,  for  programs  in  any  acquisition  category.  If  it  is  not  practicable  to  use  a 
performance  specification,  a  non-government  standard  shall  be  used.”  Secretary  Perry 
allowed  the  use  of  military  specifications  and  standards  in  cases  where  performance 
specifications  or  non-government  standards  are  not  cost  effective.  But  a  waiver  for  their 
uses  must  be  granted  by  the  Milestone  Decision  Authority  (MDA)  for  the  defense 
program.  The  memorandum  went  on  to  state  that  military  specifications  and  standards 
listed  in  the  DFARS,  such  as  the  CALS  initiative’s  military  specifications  and  standards, 
are  no  longer  mandatory  and  should  be  viewed  as  only  guidance  by  program  managers. 
(DoD  OSD,  1994,  pg.  2) 
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2. 


Guidance 


This  section  will  describe  the  two  guides  applicable  to  Department  of  the  Navy 
acquisition  managers.  Both  are  available  in  digital  form  from  the  NTIS. 

a.  DoD  CALS  Implementation  Guide 

The  DoD  Implementation  Guide  for  CALS  is  a  Military  Handbook  (MIL- 
HDBK-59B)  prepared  by  the  DoD  CALS  &  EDI  Office  with  the  assistance  of  the  military 
departments,  federal  agencies  and  the  defense  industry.  Applicable  to  all  the  military 
departments  and  DoD  Agencies,  this  handbook  addresses; 

•  CALS  strategy; 

•  DoD  CALS  policy; 

•  Acquisition  process  guidance; 

•  Special  considerations  for  existing  defense  systems; 

•  Infrastructure  modernization. 

b.  Navy/Marine  Corps  Manager’s  Desktop  Guide  for  CALS 
Implementation 

This  guide  in  its  third  edition  dated  30  September  1994,  is  produced  by  the 
Navy  CALS  Resource  and  Implementation  Cooperative  (RIC)  at  the  Naval  Air  Warfare 
Center,  Aircraft  Division,  Indianapolis.  At  over  450  pages  in  length,  it  provides  invaluable 
guidance  for  DoN  activities  seeking  information  about  the  CALS  initiative  and  its 
standards  and  specifications. 

3.  CALS  Standards  and  Standardization  Documents 

To  achieve  the  goal  of  digital  data  interchange,  definition  of  data  standards  is 
considered  a  necessity.  The  CALS  policy  is  to  adopt  private  sector  (i.e.,  non-government) 
data  standards,  which  are  anticipated  to  have  long  life-spans.  The  definition  of  the  data 
storage  and  retrieval  system,  which  is  anticipated  to  have  a  shorter  life-span,  is  left  to 
users.  This  section  discusses  the  differences  between  a  CALS  Standard  and  a  CALS 
Standardization  Document.  It  concludes  with  a  discussion  of  the  standardization  process. 
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a.  CALS  Standards 

A  CALS  Standard  is  considered  to  be  a  non-government  data  standard  that 
is  approved  by  a  standards-setting  organization  such  as  the  American  National  Standards 
Institute  (ANSI)  or  the  International  Standards  Organization  (ISO).  These  standards  are 
intended  to  function  at  the  Presentation  Layer  and  Application  Layer  of  the  Open  Systems 
Interconnection  (OSI)  Reference  Model.  Examples  of  CALS  Standards  include; 

•  ANSI  Y14.26M,  Initial  Graphics  Exchange  Specification  (IGES); 

•  ANSI  X3 . 1 22,  Computer  Graphics  Metafile  (CGM); 

•  ISO  8879,  Standard  Generalized  Markup  Language  (SGML). 

b.  CALS  Standardization  Documents 

CALS  Standardization  Documents  are  the  DoD  interpretations  and 
implementations  of  a  non-government  data  standard.  Examples  of  CALS  Standardization 
Documents  include: 

•  MIL-D-28000,  Digital  Representation  for  Communication  of  Product  Data; 
IGES  Application  Subsets; 

•  MIL-D-28001,  Markup  Requirements  and  Generic  Style  Specification  for 
Electronic  Printed  Output  and  Exchange  of  Text; 

•  MIL-R-28002,  Requirements  for  Raster  Graphics  Representation  in  Binary 
Format; 

•  MIL-D-28003,  Digital  Representation  for  Communication  of  Illustration  Data: 
CGM  Application  Profile. 

These  Standardization  Documents  will  be  explained  in  greater  detail  in  the 
next  chapter,  “CALS  Data  Format  Specifications.” 

c.  Standardization  Process 

The  practice  of  the  DoD  to  use  a  non-government  standard  in  the  CALS 
initiative  stems  from  the  desire  to  reap  the  benefits  of  using  recognized  standards  with  an 
installed  base  of  users.  The  hope  is  this  criterion  will  ensure  a  wide  choice  of 
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implementation  tools  and  the  resultant  reduction  in  procurement  and  life-cycle  costs  for  a 
system. 

The  DoD  chooses  CALS  standards  from  the  following  organizations  that 
are  listed  in  decreasing  order  of  preference: 

•  International  standards  body  such  as  the  International  Standards  Organization 
(ISO); 

•  National  standards  body  such  as  the  American  National  Standards  Institute 
(ANSI); 

•  Industry  professional  society  such  as  the  Institute  of  Electrical  and  Electronic 
Engineers  (IEEE); 

•  A  de-facto  industry  standard  if  no  other  choice  is  available. 

The  DoD  and  the  defense  industry  have  agreed  upon  a  six-step  process  to 
select  and  implement  a  standard  for  the  CALS  initiative.  In  practice  for  over  three  years, 
these  steps  are  listed  below  (Smith  and  Ellis,  1994): 

1 .  Identify  the  standardization  requirement; 

2.  Initiate  a  standardization  project; 

3.  Develop  the  necessary  standardization  document; 

4.  Coordinate  the  draft  standardization  document; 

5.  Resolve  any  comments  generated  by  the  coordination  review;  and 

6.  Publish  the  approved  standardization  document. 

E.  IMPLEMENTATION  OF  THE  CALS  STRATEGY 

The  Department  of  Defense’s  goal  for  the  CALS  strategy,  as  described  in  MIL- 
HDBK-59B,  is  transition  of  weapon  system  acquisitions  from  a  paper-based  system  to  one 
where  all  technical  data  is  in  digital  formats  and  managed  automatically.  The  envisioned 
implementation  of  this  goal  is  the  Integrated  Weapon  Systems  Data  Base  (IWSDB).  In 
the  IWSDB  all  technical  data  related  to  a  weapon  system  is  logically  stored  in  one  data 
base.  This  logical  data  base  is  accessible  to  the  DoD  acquisition  managers,  contractors 
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and  their  sub  contractors,  DoD  logistics  support  activities,  and  the  end  users.  (DoD 
CALS  Office,  1994,  pg.  4) 

The  remainder  of  this  section  describes  the  four  target  areas  in  a  weapon  systems 
life-cycle  that  need  to  be  addressed  for  implementation  of  the  CALS  strategies  and 
objectives.  This  section  concludes  by  presenting  acquisition  process  guidance  for  weapon 
system  acquisition  managers  who  intend  to  implement  CALS  strategies  and  objectives. 

1.  Target  Areas  for  Implementation  of  the  CALS  Strategy 

This  section  presents  the  four  areas  during  a  typical  weapon  system’s  life-cycle 
that  require  attention  when  attempting  to  implement  the  CALS  strategy. 

a.  Infrastructure  Modernization 

Infrastructure  modernization  refers  to  removing  filing  cabinets,  typewriters, 
printing  presses,  copier  machines  and  replacing  them  with  computer  and 
telecommunications  technology.  This  strategy  must  be  pursued  within  the  requirements  of 
existing  Federal  Information  Processing  Systems  (FIPS)  guidance  and  should  follow  an 
open-system,  scaleable,  standards-based  architecture.  This  strategy  is  being  achieved  by 
two  methods: 

1 .  Development  of  a  Joint  Service  system  that  has  the  target  architecture;  and 

2.  Migration  of  existing  systems  to  the  CALS  requirements  through  modification 
and  upgrades. 

h.  Process  Improvement 

Process  improvement  indicates  the  need  for  examination  of  current 
practices  with  paper-based  acquisition  procedures  and  evaluating  whether  the  procedures 
are  still  valid  in  an  automated  acquisition  environment  with  digital  data.  Reengineering 
and  business  process  improvement  are  some  of  the  techniques  that  will  need  to  be  used  to 
avoid  the  temptation  of  simply  automating  what  may  be  a  faulty  process. 

c.  Digital  Data  Acquisition 

Acquisition  of  digital  data  is  the  bold  step  of  accepting  technical 

documentation  of  a  weapon  system  in  digital  formats  rather  than  in  “camera-ready  copy” 
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or  “final  reproducible  copy”  formats.  Interchange  and  exchange  of  digital  data  over  a 
variety  of  computer  systems  will  require  standardization  of  digital  data  formats  and  data 
interchange  procedures. 

d.  Integration 

This  fourth  target  area  for  implementation  is  the  definition  of  a  logical  data 
structure  for  all  weapon  system  information.  This  will  ensure  all  related  data  will  be 
maintained  in  a  common  data  base,  such  as  the  fWSDB  concept,  over  the  life-cycle  of  that 
weapon  system.  (DoD  MIL-HDBK-59B,  1994,  pp.  4-5) 

2.  Acquisition  Process  Guidance 

This  section  describes  how  the  CALS  strategies  and  objectives  are  implemented  in 
the  acquisition  of  a  typical  defense  system. 

a.  Acquisition  Planning  Process 

The  Defense  Federal  Acquisition  Regulation  Supplement  (DFARS)  Part 
207.105  requires  the  acquisition  plan  for  a  weapon  system  to  include  a  description  of  how 
the  CALS  initiative  has  been  incorporated  in  life-cycle  cost  considerations.  The 
acquisition  plan  should  include  the  program’s  strategy  for  acquiring  and  managing  the 
technical  data  associated  with  a  weapon  system  in  digital  formats.  Since  each  weapon 
system  procurement  has  unique  technical  data  and  information  requirements,  the  program 
office  in  their  strategy  for  digital  data  acquisition  and  management,  should  address  the 
following  issues:  infrastructure,  data  access,  data  management,  data  flow,  and  data 
exchange.  (DoD  CALS  Office,  1994,  pg.  9) 

The  CALS  Government  Concept  of  Operations  (GCO)  is  a  document 
prepared  by  the  weapon  system  program  office  during  the  acquisition  planning  process.  It 
describes  to  potential  offerors  what  the  iiffiastucture  and  CALS  implementation  strategy 
will  be  for  the  particular  weapon  system  program.  The  GCO  is  usually  prepared  once  the 
program  office  has  received  inputs  from  all  the  defense  activities  expected  to  support  the 
weapon  system  during  its  life-cycle.  It  is  included  as  Government  Furnished  Information 
(GFI)  within  the  Request  For  Proposal  (RFP). 
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Specific  guidance  for  developing  a  GCO  and  a  sample  questionnaire  is 
contained  in  MIL-HDBK-59B,  Annexes  E  and  F.  The  major  points  of  a  GCO  may 
include: 

•  Identification  of  data  type  deliverables; 

•  Identification  of  data  users; 

•  Identification  of  data  use  and  processing; 

•  Identification  of  data  user  infrastructure; 

•  Identification  of  data  delivery  and  type; 

•  Identification  of  data  format; 

•  Identification  of  data  interchange  standards;  and 

•  Determination  of  mechanism  and  types  of  media  for  data  delivery  and  access. 

b.  Solicitation  and  Selection  Process 

Completion  of  the  acquisition  process  planning  stage  and  formulation  of  a 
CALS  Government  Concept  of  Operations  firmly  grounds  the  weapon  system  acquisition 
management  team  in  the  CALS  principals  as  it  enters  the  solicitation  and  source  selection 
process.  During  the  solicitation  and  selection  process,  the  most  critical  element  is  for 
acquisition  managers  to  communicate  their  CALS  implementation  strategy  in  the  RFP. 
MIL-HDBK-59B  contains  explicit  examples  of  how  CALS  language  may  be  incorporated 
in  an  RFP  in  order  that  the  potential  offerors  understand  exactly  how  CALS  principals  will 
be  implemented  in  this  particular  weapon  system  program. 

Section  L  of  a  RFP  contains  the  Instructions  to  Offerors  (ITO).  This 
section  is  used  to  instruct  potential  bidders  to  submit  a  Contractors  Approach  to  CALS 
(CAC).  The  CAC  is  a  comprehensive  document  detailing  the  contractor’s  “approach, 
experiences,  and  successes  in  the  creation,  management,  use,  and  exchange  of  digital 
information”  (DoD  CALS  Office,  1994,  pg.  22).  This  document  can  be  useful  to  the 
program  office  in  evaluating  the  contractor’s  capabilities  to  create  and  manage  digital  data 
as  specified  in  the  RFP.  This  section  may  also  be  used  to  solicit  alternative  proposals  from 
potential  contractors  such  as  alternate  delivery  methods  of  data  requirements  specified  in 
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the  RFP.  These  alternate  proposals  should  be  aimed  at  reducing  life-cycle  costs  for  the 
weapon  system  and  thus  must  be  submitted  with  supporting  cost  and  benefit  justification 
information.  (DoD  CALS  Office,  1994,  pg.  23) 

c.  Implementation  Process 

The  implementation  process  for  the  CALS  strategy  involves  a  three-part 
approach:  on-line  services;  digital  data  delivery;  and  integration  of  product,  process,  and 
data.  The  implementation  process  encompasses  the  input  of  specified  data  elements  from  a 
weapon  system  contract.  The  data  elements  are  developed  using  CALS  military 
standards;  data  format  specifications;  and  product,  process  and  data  integration  standards. 
These  are  provided  in  a  CALS/Concurrent  Engineering  environment  to  yield  CALS  digital 
data  products  useful  for  the  weapon  system’s  life-cycle.  (DoD  CALS  Office,  1994,  pg. 
24) 

F.  CALS  INFRASTRUCTURE  MODERNIZATION  SYSTEMS 

This  section  describes  the  two  “flagship”  CALS  systems:  Joint  Computer-aided 
Acquisition  and  Logistics  Support  (JCALS)  and  the  Joint  Engineering  Data  Management 
Information  and  Control  System  (JEDMICS). 

1.  Joint  Computer-aided  Acquisition  and  Logistics  Support 

The  CALS  implementation  target  area,  infrastructure  modernization,  has  been 
realized  in  the  Joint  Computer-aided  Acquisition  and  Logistics  Support  (JCALS)^ 
Program,  The  JCALS  concept  originated  from  the  US  Army’s  Technical  Information 
Management  System  (TIMS),  which  became  the  Army  CALS  (ACALS)  program  in 
March  1987.  In  January  1991,  the  Army  was  directed  to  transition  ACALS,  already  in 
Phase  I  of  its  development  by  Computer  Sciences  Corporation  (CSC)  of  Moorestown,  NJ, 
to  include  joint  requirements  and  to  make  it  a  joint  program.  The  Joint  CALS  concept 
was  demonstrated  by  two  contractors  in  February  1991  and  was  designated  a  joint  service 
program  in  October  1991.  CSC  was  awarded  the  JCALS  contract,  valued  at  $  744  million 

2  Although  the  DoD  has  changed  the  CALS  to  Continuous  Acquisition  and  Life-Cycle  Support,  the 
JCALS  Program  Office  has  retained  the  older  meaning  for  CALS,  Computer-aided  Acquisition  and 
Logistics  Support. 
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if  all  options  are  exercised,  in  December  1991  (Zurier,  1993,  pg.  S4).  The  program  is 
currently  in  Phase  III.  The  remainder  of  this  section  describes  the  JCALS  system  design, 
implementation,  components,  and  future  developments. 

a.  System  Design 

JCALS  is  an  information  management  system  that  will  support  acquisition, 
logistics  support,  engineering,  manufacturing,  configuration  control  and  materiel 
management  processes  throughout  the  life-cycle  of  a  weapon  system.  It  uses  multi¬ 
weapon  system  IWSDBs  and  Global  Data  Dictionary  and  Directory  (GDD/D)  Services 
that  are  connected  by  a  wide  area  computer  network.  The  interface  for  users  is  the 
JCALS  Workbench  that  provides  an  environment  to  access  all  of  JCAL’s  functionality 
transparently  to  the  user.  JCALS  was  designed  within  the  CALS  requirements  and  CIM 
Technical  Reference  Model  (TRM)  architecture.  It  uses  open  systems  standards,  making 
it  flexible  and  scaleable.  (DoD  MIL-HDBK-59B,  1994,  pg.  34) 

The  design  specifications  for  JCALS  indicate  that  it  can  have  a  bi¬ 
directional  interface  with  Contractor  Integrated  Technical  Information  Services  (CITIS) 
and  Electronic  Data  Interchange  (EDI)  suppliers  over  a  Wide  Area  Network  (WAN). 
CITIS  is  an  information  system  furnished  by  a  defense  contractor  that  provides  access  to 
the  technical  data  and  information  associated  with  a  defense  system  contract  to 
government  acquisition  managers  and  technical  representatives.  This  bi-directional 
interface  can  be  one  or  more  of  the  four  types  listed  below  (DoD  MIL-HDBK-59B,  1994, 
37); 

1 .  non-interactive  data  exchange  using  removable  digital  media; 

2.  selected  CITIS  functions  using  dial-up  or  network  access  capabilities; 

3 .  on-line  interface  where  data  dictionaries  are  mapped  to  each  other  for 
transparent,  seamless  access;  and 

4.  fully  integrated,  JCALS  site-type  interface  for  which  the  contractor  is  furnished 
GDD/D  services,  software  and  if  required,  equipment. 
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b.  System  Deployment 

Presently  JCALS  is  in  prototype  at  six  DoD  sites;  Marine  Corps  Logistics 
Base  Albany,  GA;  Marine  Corps  Base  Quantico,  VA;  Tinker  Air  Force  Base  (AFB),  OK; 
Wamer-Robbins  AFB,  GA;  Naval  Surface  Warfare  Center  (NSWC),  Port  Hueneme,  CA; 
and  the  Army’s  Missile  Command  in  Huntsville,  AL. 

JCALS  also  has  four  Technology  Application  Sites  currently  located  at: 
Los  Angeles  AFB,  Los  Angeles,  CA;  Peterson  AFB,  Colorado  Springs,  CO;  McClellan 
AFB,  Sacramento,  CA;  and  NSWC,  Dahlgren,  VA.  If  fully  deployed,  JCALS  will 
eventually  have  245  sites  connected  over  the  Defense  Information  Systems  Network. 
Delivery  of  the  first  JCALS  system  is  expected  to  begin  in  the  first  half  of  1996. 

c.  System  Configuration 

The  JCALS  software  is  a  suite  of  commercial  off-the-shelf  software 
(COTS)  and  Government  Owned  Software  (GOTS)  that  are  integrated  by  CSC  with 
custom  Ada  code.  Current  COTS  packages  include:  Oracle  Corporation’s  Trusted 
Oracle  7  database  management  system.  Digital  Equipment  Corporation’s  (DEC) 
Multilevel  Secure  Plus  Operating  System,  ArborText  Incorporated’s  AdeptPublisher,  and 
numerous  utility  and  viewer  applications.  CSC  states  that  COTS  (which  are  designed  into 
the  X-Windows  operating  system  to  provide  consistent  user  interfaces)  currently  make  up 
about  95  percent  of  the  JCALS  software  suite  (Endoso,  1994,  pg.  39). 

The  GOTS  portions  of  JCALS  include  a  Workflow  Manager  application 
created  in  the  Ada  programming  language,  the  Global  Data  Base  Manager  (GDMS),  and 
the  Reference  Library.  The  workflow  manager  application  provides  a  user  tool  for 
analysis  using  the  principals  of  Business  Process  Reengineering  involving  digital  data.  A 
completed  workflow  will  contain  all  the  database  links  necessary  between  the  individuals 
and  technical  data  associated  with  a  particular  process.  The  Reference  Library  is  a 
repository  for  publications,  documents,  engineering  drawings  and  illustrations  that  are 
accessible  to  JCALS  users  through  the  Reference  Library  Search  tool.  Depending  on  an 
individual’s  access  rights,  a  user  may  either  view  or  review  and  annotate  any  document 
contained  in  the  Reference  Library. 

A  typical  JCALS  site  will  have  a  Fiber-optic  Distributed  Data  Interface 
(FDDI)  backbone  ring  with  the  JCALS  engine  consisting  of  the  GDMS,  Network 
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Processor  and  Internet  Protocol  Router.  The  JCALS  work  group  consists  of  DEC  Alpha 
workstation  servers,  X-terminal  workstations,  and  various  other  peripheral  devices.  This 
hardware  is  interconnected  by  Ethernet  cabling.  Figure  1  depicts  a  typical  JCALS  system 
configuration. 

Presently,  the  only  application  developed  by  CSC  that  is  operational  on  the 
JCALS  infi'astructure  is  the  Technical  Manual  Management  System  (TMMS).  This 
system  permits  users  to  acquire,  manage,  and  author  technical  manuals  including  the 
production  of  reproducible  copies,  in  either  digital  or  paper  formats.  The  TMMS  system 
integrates  the  common  user  interface  (workfolder  concept),  workflow  management 
application,  and  the  GDMS  access  to  technical  data.  (Gourley,  1995,  pp.  20-21) 

d.  Recent  Developments  and  Future  Enhancements 

Through  each  software  upgrade  to  JCALS,  performance  enhancements  and 
improved  capabilities  have  been  added  to  the  different  software  modules.  In  JCALS’  most 
recent  software  upgrades,  a  PC  client  application  and  a  basic  interface  to  JEDMICS,  and 
several  other  DoD  information  systems  were  added.  Future  JCALS  enhancements  will 
include  integration  of  COTS  applications  (such  as  Adobe  Systems  Acrobat  Press  and 
Reader)  and  providing  multimedia  capabilities  for  the  authoring  and  creation  of  Interactive 
Electronic  Technical  Manuals  (lETMs). 
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Figure  1.  JCALS  System  Configuration 

2.  Joint  Engineering  Data  Management  Information  and  Control 

System 

The  Joint  Engineering  Data  Management  Information  and  Control  System 
(JEDMICS)  is  a  CALS-compliant  repository  for  the  storage  of  engineering  drawings  and 
related  technical  data.  It  originates  from  the  Engineering  Data  Management  Information 
and  Control  System  (EDMICS).  EDMICS  was  a  Navy  program  vrith  a  ten  year  firm-fixed 
price  indefinite-delivery,  indefinite-quantity  contract.  It  had  been  awarded  to  PRC,  Inc.  of 
Reston,  VA  in  1989.  The  EDMICS  program  was  validated  as  a  program  meeting  the 
CALS  initiative  strategies  and  objectives  in  1991  and  selected  as  a  tri-service  program 
later  that  year.  In  1993  EDMICS  was  chartered  as  a  joint  program  by  DoD  and  renamed 
JEDMICS.  The  Navy  retained  management  responsibilities  for  the  program. 

a.  System  Design 

JEDMICS  consists  of  six  subsystems  that  permit  users  on-line  access  to 
engineering  drawings  and  related  technical  data  stored  in  CALS  data  formats.  The  six 
subsystems  (input,  data  integrity,  index,  storage,  output,  and  remote  output)  follow  a 
standard  open  system  design  in  a  client-server  architecture.  The  subsystems  are  scaleable 
and  compatible  with  existing  applications  and  information  systems  at  a  particular 


JEDMICS  site.  JEDMICS  supports  the  input  and  output  of  paper  drawings,  text  pages, 
aperture  cards.  Computer-aided  Design  (CAD)  files,  magnetic  tapes,  optical  players,  and 
direct  connections  to  and  from  other  information  systems.  It  maintains  the  drawings  and 
technical  data  in  the  following  CALS  file  formats;  Raster,  ASCII,  binary,  2D/3D  vector, 
SGML,  IGES,  and  CGM. 

b.  System  Deployment 

Presently  there  are  twenty-four  JEDMICS  sites  installed  at  Navy,  Army, 
Air  Force,  and  Defense  Logistics  Agency  sites.  A  typical  JEDMICS  site  will  include 
maintenance  and  logistics  activities  such  as  Naval  shipyards,  the  Marine  Corps  logistics 
bases.  Army  depots.  Air  Force  depots  and  Defense  supply  centers  that  require  access  to 
engineering  drawings. 

c.  System  Configuration 

JEDMICS  consists  of  GOTS  and  COTS  software  that  are  integrated 
through  a  JEDMICS  Application  Program  Interface  (API)  that  permits  the  software  to 
operate  in  a  C-2  level  secure,  client-server  environment.  The  custom  GOTS  applications 
provide  for  indexing,  retrieval,  security,  backup,  archiving,  import/export,  and 
management  reporting.  The  COTS  applications  include  the  Oracle  database  management 
system,  UNIX  operating  system  and  various  utility  applications  for  viewing  and  converting 
the  variety  of  data  file  formats. 

Current  server  platforms  include  Digital  Equipment  Corporation  (DEC) 
VAXA^S  mainframe  computers,  Silicon  Graphics  and  Hewlett  Packard  workstations. 
Client  platforms  include  workstations  and  microcomputers  from  DEC,  Sun  Microsystems, 
Intergraph,  Silicon  Graphics,  and  numerous  desktop  microcomputers  running  various 
operating  systems  and  application  programs.  JEDMICS  uses  Kodak  optical  jukeboxes  as 
the  storage  device  for  engineering  drawings  and  technical  data. 

d.  Recent  Developments  and  Future  Enhancements 

The  JEDMICS  API  developed  in  1994  permits  JEDMICS  to  operate  with 
other  information  systems  in  Local  Area  and  Wide  Area  Network  environments.  In 
October  1994  the  interface  between  JEDMICS  and  JCALS  was  demonstrated  when  a  user 
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on  a  JCALS  workstation  was  able  to  query  and  retrieve  engineering  drawings  from  a 
JEDMICS  repository. 

As  the  military  services  digitize  their  technical  data  in  CALS  data  formats, 
JEDMICS  hopes  to  become  the  standard  repository  for  all  technical  data,  including 
technical  manuals.  Continued  improvements  to  JEDMICS’  interface  and  access  methods, 
will  allow  DoD  and  private  sector  engineering,  planning,  logistics,  training,  and 
maintenance  organizations  to  share  the  same  techmcal  data  throughout  the  life-cycle  of  a 
defense  system. 
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III.  CALS  DATA  FORMAT  SPECIFICATIONS 


This  chapter  presents  the  CALS  specifications  and  standards  related  to  the 
publishing  of  technical  data.  The  word  “publishing”  means  to  prepare  and  issue  (the 
assumption  is  printed  material)  for  public  distribution  or  sale.  Under  the  CALS  initiative, 
the  specifications  and  standards  relating  to  the  production  of  technical  data  has  automated 
the  exchange  of  illustrations,  drawings,  text,  images,  and  graphics  used  in  technical 
documentation.  This  chapter  describes  four  of  the  most  significant  military  specifications 
and  standards  relating  to  producing  technical  data  and  publishing  technical  manuals. 
These  specifications  are  known  as  the  CALS  Data  Format  Specifications  and  are 
commonly  referred  to  as  the  “28000  series  specs,” 

A.  MIL-D-28000A 

The  MIL-D-28000A  military  specification  is  an  example  of  a  CALS 
standardization  document  that  provides  implementation  guidance  for  an  industry  standard. 
It  addresses  the  digital  representation  of  product  definition  data  using  a  subset  of  the 
Initial  Graphics  Exchange  Specification  (IGES)  as  defined  by  the  American  Society  of 
Mechanical  Engineers  standard  Y14.26M  (Digital  Representation  for  Communication  of 
Product  Definition  Data).  MIL-D-28000A’s  full  title  is  “Digital  Representation  for 
Communication  of  Product  Data:  IGES  Application  Subsets  and  IGES  Application 
Protocols.” 


1.  Purpose  and  Applicability 

This  standard  relates  to  the  interchange  of  Computer  Aided  Design  (CAD)  system 
generated  drawings  between  two  applications  fi'om  two  different  software  vendors.  This 
section  describes  how  MIL-D-28000A  provides  for  this  interchange  through  the  definition 
of  Classes,  Application  Subsets,  and  Application  Protocols. 

a.  Classes  and  Application  Subsets 

MIL-D-28000A  specifies  only  five  of  all  the  possible  classes  within  the 
IGES  standard.  These  classes  are: 
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•  Class  I,  Technical  Illustrations  Subset; 

•  Class  II,  Engineering  Drawings  Subset; 

•  Class  III,  Electrical/Electronic  Applications  Subset; 

•  Class  rV,  Geometry  for  Numeric  Control  Manufacturing  Subset;  and 

•  Class  V,  3D  Piping  Application  Subset. 

The  IGES  standard  is  considered  to  be  a  voluminous  standard  with  the 
flexibility  of  allowing  a  variety  of  ways  to  represent  the  same  Computer  Aided  Design 
(CAD)  model  entity.  CAD  vendors  usually  only  provide  a  subset  of  the  IGES  standard 
for  use  in  their  CAD  applications.  When  entities  are  exchanged  between  different  CAD 
applications,  mismatches  inevitably  occur  between  IGES  entities  in  use  by  the  two  CAD 
systems. 

The  first  four  of  the  classes  listed  above  explicitly  specify  the  entities 
required  for  their  Application  Subsets.  A  provision  in  the  standard  is  made  for  a 
“volunteer  entity”  for  the  purpose  of  recreating  the  environment  of  the  transmitting  CAD 
system  on  the  receiving  CAD  system.  (Garner,  et.  al.,  1994,  pg.  3-2) 

b.  Application  Protocols 

When  interchanging  product  data  using  the  IGES  standard,  the  Application 
Protocol  (AP)  defines  the  user  requirements  for  the  applications  based  on  the  Application 
Reference  Model.  The  AP  is  specific  for  a  particular  class  of  drawings  and  provides  the 
means  for  how  information  is  mapped  into  the  required  IGES  entities. 

c.  Vendor  Support 

Most  CAD  application  software  vendors  today  provide  some  level  of  IGES 
compatibility  with  a  translating  routine.  Vendor  support  for  MIL-D-28000A  is  not  as 
prevalent  as  for  the  full  IGES  standard,  though  some  of  the  classes  are  supported  more 
than  others.  Currently  Class  II,  engineering  drawings,  and  Class  I,  technical  drawings,  are 
the  two  most  supported  classes  within  MIL-D-28000A.  There  is  at  least  one  non-CAD 
software  application,  the  Interleaf  document  publishing  system,  that  provides  support  for 
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both  the  IGES  standard  and  Classes  I  and  II  of  MIL-D-28000A.  (Gamer,  et.  al.,  1994, 
pg.  3-7) 

2.  Future  of  Standard 

This  standard  is  dependent  on  the  IGES  standard  version  5.1  and  the  American 
National  Standard  Y14.26M  of  1989.  The  CALS  Evaluation  &  Integration  Office  works 
closely  with  the  standards  organizations  through  the  organization’s  CALS/IGES  Special 
Interest  Group.  This  group  actively  reviews  proposed  changes  and  makes  inputs  on  how 
the  standard  can  be  improved  through  revisions.  (Gamer,  et.  al.,  1994,  pg.  3-5) 

B.  MIL-M-28001B 

This  military  specification  was  one  of  the  most  controversial  parts  of  the  CALS 
initiative  when  it  was  first  issued  in  1988.  As  a  standardization  document  now  in  its 
second  revision,  it  is  intended  to  provide  implementation  guidance  for  the  international 
standard  ISO  8879,  “Standard  Generalized  Markup  Language  (SGML).”  This  military 
specification  today,  has  become  widely  accepted  by  software  vendors  and  national  and 
international  defense  industries. 

1.  Purpose  and  Applicability 

MIL-M-28001B,  “Markup  Requirements  and  Generic  Style  Specification  for 
Electronic  Printed  Output  and  Exchange  of  Text,”  sets  out  the  requirements  for  the 
delivery  of  page-oriented  technical  documentation  in  digital  form.  This  specification’s 
intent  is  to  ensure  that  documents,  prepared  with  authoring  tools  compliant  with  the  ISO 
standard,  may  be  automatically  stored,  retrieved,  interchanged  and  processed  among 
differing  computer  hardware  and  software  systems  at  government  and  contractor  sites. 

The  specification  details  the  procedures  and  symbology  for  the  markup  of 
unformatted  text  using  the  SGML  standard  for  the  purposes  of  encoding  and  formatting 
technical  publications  using  Document  Type  Definitions  (DTDs).  Further,  the 
specification  sets  out  the  requirements  for  how  technical  documentation,  encoded  in 
SGML,  can  be  printed  in  a  format  compatible  with  the  existing  military  specification  for 
technical  manuals  and  technical  publications,  MIL-M-38784C.  This  output  of  SGML 
encoded  text  is  accomplished  by  the  creation  of  a  Formatting  Output  Specification 


Instance  (FOSI)  based  on  MIL-M-2 800 IB’s  Output  Specification  (OS).  Specific  details 
about  DTDs,  OS,  and  FOSI  are  presented  in  the  section  title  “SGML  Constructs  and  the 
Document  Style  Semantics  and  Specification  Language”  that  follows. 

Appendix  C  of  MIL-M-28001B  provides  information  on  how  a  review  and 
comment  capability  can  be  incorporated  into  a  SGML  publishing  environment.  This 
capability  is  invaluable  when  documents  in  preliminary  form  must  be  sent  by  the  contractor 
to  the  government  for  review  before  they  can  be  issued  in  final  form.  (Gamer,  et.  al., 
1994,  pg.  4-6) 

a.  Advantages 

The  chief  advantage  of  this  specification  is  its  ratification  of  SGML  as  a 
means  for  the  interchange  of  ASCII  text  data.  With  ISO  8879  being  an  international 
standard,  it  makes  document  production  and  management  easier  by  offering  a  method  of 
authoring,  storing  and  managing  documents  without  the  constraints  of  proprietary 
computer  hardware  configurations  and  software  applications. 

b.  Military  Handbook  SGML 

Military  Handbook  SGML  (MIL-HDBK-SGML)  offers  additional 
guidance  for  application  of  MIL-M-2 800  IB  and  ISO  8879.  Issued  by  the  DoD  CALS  and 
EDI  Office,  it  is  currently  in  draft  form  dated  21  June  1993.  It  is  expected  to  be  issued  in 
final  form  in  1995  and  will  be  available  from  the  NTIS  in  digital  formats.  The  substantive 
portion  of  the  handbook  provides  an  overview  of  SGML  from  the  perspective  of  how  it 
fits  within  the  CALS  strategy  and  then  provide  sections  that  describe  the  following  tasks 
for  an  SGML  user; 

•  Performing  a  document  analysis 

•  Developing  a  DTD  based  on  a  document  analysis 

•  Tagging  textual  information  based  on  a  DTD 

•  Preparing  a  FOSI  in  accordance  with  the  OS  in  MIL-M-28001B 

•  Using  the  SGML  Reuse  Library  and  SGML  Tagset  Registry.  (MIL-HDBK- 
SGML,  1993,  pg.  1) 
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The  SGML  Reuse  Library  and  SGML  Tagset  Registry  have  been  created 
by  the  Electronic  Publishing  Committee  of  the  CALS  ISG  to  serve  as  the  repository  for 
SGML  constructs  used  in  CALS  applications.  The  Reuse  Library  maintains  SGML 
constructs  such  as  DTDs  (and  fragments  thereof)  and  FOSIs  while  the  Tagset  Registry 
maintains  constructs  such  as  elements,  attributes,  and  entities.  (MIL-HDBK-SGML, 
1993,  pg.  86)  The  Navy  has  developed  a  Navy  Baseline  Tagset  that  includes  tags  for  use 
with  the  technical  manual  specification  MIL-M-38784C  to  minimize  the  proliferation  of 
differing  tags  and  duplicate  definitions  for  tags. 

c.  Vendor  Support 

Numerous  products  that  support  SGML  publishing  requirements  currently 
exist  in  mainframe,  UNIX  and  Microsoft  DOSAVindows  operating  environments.  SGML 
applications  to  visualize  the  hierarchical  nature  of  DTDs,  create  new  DTDs,  and  convert 
WordPerfect  and  Microsoft  Word  document  styles  to  DTDs  have  been  in  existence  since 
1993.  Complete  SGML  authoring  environments  allow  the  user  to  accomplish  SGML 
publishing  with  varying  degrees  of  ease  of  use.  Public  domain  SGML  parsers,  and  DTD 
creation  software  applications  for  the  DOS  operating  system,  are  in  existence  and  are 
useful  for  academic  purposes  and  smaller  SGML  implementations. 

SGML  publishing  software  vendors  have  implemented  the  ISO  8879 
SGML  standard  to  their  products  with  minor  variations.  These  differences  with  the 
SGML  parser  result  in  DTDs  and  FOSIs  created  by  one  vendor’s  application  not 
successfully  parsing  or  displaying  in  another  vendor’s  application.  While  these  differences 
are  minor  in  most  cases,  they  only  add  to  the  fhistration  of  users  when  two  applications 
that  claim  compliance  with  an  international  standard  are  not  seamlessly  compatible  vrith 
each  other. 

Vendors  have  been  careful  not  to  tie  their  product  too  closely  to  this  still 
evolving  military  specification,  lest  the  alienation  of  the  civilian  commercial  market.  Some 
of  the  most  significant  SGML  implementations  have  occurred  in  the  aviation,  automotive 
and  heavy  equipment  industries.  Nearly  all  the  major  software  vendors  participate  in  the 
Electronic  Publishing  Committee  of  the  CALS  Industry  Standards  Working  Group,  which 
is  the  primary  organization  responsible  for  the  development  of  MIL-M-28001.  This 
committee  reviews  comments  on  proposed  amendments  and  future  revisions  of  the 
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standard  that  are  generated  by  government  and  industry  users  of  the  standard.  (Gamer,  et. 
al.,  1994,  pg.  4-9) 

2.  SGML  Constructs  and  the  Document  Style  Semantics  and 

Specification  Language 

This  section  describes  tAvo  SGML  constmcts  in  greater  detail  and  includes  an 
example  of  a  Document  Type  Definition  and  an  example  of  a  Formatting  Output 
Specification  Instance.  This  section  concludes  with  a  description  of  the  Document  Style 
Semantics  and  Specification  Language  and  its  future  impact  on  publishing  with  SGML. 

a.  Document  Type  Definition 

A  document  type  definition  is  a  SGML  file  that  details  the  structure  of  the 
information  for  a  particular  document.  Its  creation  is  usually  the  result  of  a  group  effort 
among  individuals  having  adequate  working  knowledge  of  SGML  and  familiarity  with  a 
certain  type  of  document,  a  technical  manual  for  instance.  The  group  begins  document 
analysis  by  ignoring  the  formatting  characteristics  of  the  document  and  only  studying  how 
information  within  the  document  is  stmctured.  Only  then  will  the  group  be  able  to  begin 
to  create  a  DTD. 

The  DTD  is  an  ASCII  text  file  that  contains  the  declarations,  or  elements, 
that  describe  how  the  information  within  a  document  is  stmctured.  The  DTD  is  written 
using  SGML  syntax  and  formatting  and  must  be  parsed  by  a  ISO  8879  compatible 
validating  parser^  before  it  may  be  used.  Each  of  these  elements  will  become  tags  in  the 
SGML  instance  file  indicating  the  start  and  finish  of  a  particular  segment  of  information 
within  the  document.  The  elements  in  the  DTD  may  also  have  attributes  associated  with 
them.  These  optional  attributes  provide  a  means  to  detail  the  possible  values,  including  a 
default  value,  for  an  element.  Figure  2  (top)  shows  a  DTD  for  an  office  memorandum. 
The  actual  memorandum,  as  an  SGML  document  instance,  is  shown  in  Figure  2  (bottom). 
In  summary,  the  DTD  defines  what  type  of  document  is  being  modeled,  which  elements 
are  permitted,  how  the  elements  are  sequenced,  and  what  attributes  are  possible  for  each 
element. 


^  A  validating  parser  is  a  program  that  reads  a  DTD  and  checks  whether  errors  are  present  and  provides  a 
report  if  they  are.  (van  Herwijnen,  1994,  pg.  278) 
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b. 


Output  Specification 


The  purpose  of  the  Output  Specification  (OS)  is  to  provide  a  means  to 
exchange  the  style  and  formatting  information  among  SGML  publishing  systems.  The  OS 


< !-  Lines  that  start  and  end  with  two  dashes  are  comments.  -> 

<!--  This  is  a  DTD  for  an  office  memorandum  --> 


<!  ENTITY  % 
<!- 

doctype  “MEMO” 
ELEMENTS 

MIN 

CONTENT 

> 

-> 

<!ELEMENT 

%doctype; 

((TO  &  FROM),  SUBJ,  BODY,  CLOSE) 

> 

<!  ELEMENT 

TO 

-0 

(#PCDATA 

> 

<!  ELEMENT 

FROM 

-O 

(#PCDATA) 

> 

<!ELEMENT 

SUBJ 

-o 

(#PCDATA) 

> 

<!ELEMENT 

BODY 

(PARA)* 

> 

<!  ELEMENT 

PARA 

(#PCDATA  1  LIST)* 

> 

<!  ELEMENT 

LIST 

(#PCDATA) 

> 

<!  ELEMENT 

CLOSE 

(#PCDATA) 

> 

<MEMO> 

<TO>Robert  Smith 
<FROM>John  Jones 
<SUBJ>Company  Picnic 
<BODY> 

<PARA>Here  are  my  ideas  for  activities  at  Saturday’s  picnic: 
<LIST>Volleyball,  Softball,  Horseshoes,  Square  Dancing.</LIST> 
<PARA>Let  me  know  what  you  think? 

</BODY> 

<CLOSE>Regards,  John</CLOSE> 

</MEMO>  _ 


Figure  2.  Document  Type  Definition  and  Corresponding  SGML  Document  Instance 
document  type  definition  describes  how  the  Formatting  Output  Specification  Instance 
(FOSI)  should  be  created  for  documents  that  have  their  source  data  tagged  according  to  a 
DTD. 

The  FOSI  specifies  the  layout,  formatting,  and  styles  for  the  displaying  of 
SGML  encoded  documents  in  a  page-oriented  format  using  the  publishing  software  that 
the  FOSI  was  created  on.  A  FOSI  is  written  for  a  particular  class  of  documents  that  will 
be  outputted  in  a  particular  format.  For  example,  a  FOSI  created  for  use  with  technical 
manuals  would  be  designed  to  conform  with  the  format  specified  in  MIL-M-38784C.  It 
selectively  takes  any  of  the  possible  formatting  and  style  characteristics  fi’om  the  OS  DTD 
and  details  how  they  are  to  be  used  for  outputting  a  page  of  a  technical  manual.  It  is 
important  to  note  that  because  FOSIs  specify  formatting  information,  they  are  necessarily 
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proprietary  to  the  SGML  publishing  application  or  FOSI  composition  tool  that  was  used 
to  create  the  FOSI. 


c.  Document  Style  Semantics  and  Specification  Language 

A  major  shortcoming  of  the  SGML  standard  is  the  lack  of  a  definite 
method  of  formatting  SGML  encoded  information.  Consequently,  software  vendors  have 
created  and  implemented  FOSIs,  an  extension  of  SGML,  to  specify  how  SGML  encoded 
information  can  be  outputted  in  a  particular  format  or  style  using  their  SGML  publishing 
application.  The  DoD,  with  MIL-M-28001B  and  the  OS,  followed  a  similar  route.  It 
specified  to  developers  how  to  use  the  OS  to  create  FOSIs  to  output  printed  technical 
manuals,  according  to  the  technical  manual  specification.  Formatting  instructions  in  any 
form  for  use  with  a  publishing  application  are  necessarily  proprietary.  FOSIs  are 
considered  a  necessity  until  a  better  method  could  be  developed. 

The  Document  Style  Semantics  and  Specification  Language  (DSSSL)  is  a 
language  that  allows  the  user  to  define  how  processing  information,  or  formatting,  should 
be  associated  with  a  SGML  document.  DSSSL  is  not  SGML,  but  a  query  language  that 
allows  the  user  to  identify  SGML  elements  from  the  SGML  document  instance.  Then  the 
user  may  attach  semantics  such  as  formatting,  style,  and  layout  information  to  the 
elements  from  the  DSSSL  document  architecture  (van  Herwijnen,  1994,  pg.  226). 
Presently  nearing  ratification  as  an  international  standard,  DSSSL  permits  the  specification 
of  formatting,  style,  and  layout  information  without  having  ties  to  a  particular  publishing 
application. 

3.  Future  of  Standard 

This  standard  has  oscillated  from  being  too  specific  and  directive  in  nature  to  being 
too  general.  Revision  A  of  this  standard  contained  a  DTD  modeled  after  the  technical 
manual  specification  at  the  time  MIL-M-38784B.  It  also  contained  twelve  derivative 
DTDs  based  on  the  master  DTD.  The  current  version  of  this  standard,  revision  B, 
cont^ns  only  a  sample  DTD  “template”  that  is  intended  to  be  a  “toolkit”  for  DTD 
developers.  If  this  DTD  is  taken  literally,  it  will  not  yield  a  parseable  SGML  instance. 
(Gamer,  et.  al.,  1994,  pg.  4-1)  Presently,  the  Computer  Sciences  Corporation  (CSC) 
under  the  JCALS  contract  is  designing  a  MIL-M-38784C  conforming  DTD  titled  the 
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“Quest-DTD”  in  the  JCALS  SGML  authoring  tool,  ArborText  Incorporated’s 
AdeptPublisher. 

Amendment  1  to  MIL-M-28001B  is  expected  to  be  made  public  in  early  1995  and 
will  primarily  contain  changes  to  the  OS  contmned  in  Appendix  B.  Future  revisions  of  this 
standard  should  distance  themselves  from  a  specific  class  of  documents  and  focus  on 
DoD-specific  implementation  issues  with  the  international  SGML  standard.  Guidance 
concerning  specific  DTDs  should  be  appended  with  the  military  specification  that  covers 
that  particular  class  of  documents  or  incorporated  within  MBL-HDBK-SGML.  For 
instance,  the  DTD  and  FOSI  for  technical  manuals  should  be  contained  in  an  appendix  to 
MIL-M-37874C.  Plans  for  issuing  Revision  C  of  MIL-M-28001B  are  underway,  with  its 
release  expected  in  1996  or  possibly  1997. 

C.  MIL-R-28002B 

This  military  specification  was  originally  conceived  because  of  an  absence  of 
national  and  international  standards  for  the  storage  and  exchange  of  large  engineering 
drawings  as  raster  graphics  files.  Now  known  as  a  standardization  document,  its  current 
version  is  based  on  ISO  standards  and  the  Committee  on  Telegraph  and  Telephone 
(CCITT)  recommendations. 

1.  Purpose  and  Applicability 

This  specification  details  how  a  contractor  should  deliver  raster  data  to  the 
government.  It  establishes  the  requirements  for  a  standard  interchange  file  format  and  the 
raster  encoding  scheme  for  raster  data.  Raster  data  or  graphics  are  the  digital 
representations  of  an  image  using  picture  elements.  Picture  elements  have  the 
information,  such  as  lightness,  darkness,  gray-level  and  color,  for  a  particular  portion  of 
the  image  they  represent.  The  density  of  picture  elements  vrill  determine  how  good  the 
resolution  of  the  image  will  be  in  raster  data  format  and  how  large  the  raster  data  file  will 
be  for  storage.  (Gamer,  et.  al.,  1994,  pg.  5-1) 

MIL-R-28002B  identifies  two  types  of  digital  representations,  or  file  formats,  of 
raster  data  designated  Type  I  and  Type  II.  Type  I  raster  files,  also  known  as  untiled  raster 
files,  are  the  result  of  digitizing  an  image  to  a  single  bitmap  and  then  compressing  it  into  a 
single  file.  Type  II  file  format  corresponds  to  the  Open  Document  Architecture  (ODA) 
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document  as  specified  by  ISO  8613,  “Information  Processing  -  Text  and  Office  Systems  - 
Open  Document  Architecture”  standard.  A  Type  II  representation  may  consist  either 
untiled  raster  data  with  the  ODA  parameters  and  data  structuring  or  tiled  raster  data. 
Subdivision  of  an  image  into  to  non-overlapping  segments,  or  tiles,  yields  tiled  raster  data. 
Each  of  the  tiles  is  then  handled  as  a  separate  picture  element  array.  Tiled  raster  data  is 
most  often  used  in  large  mechanical  drawings  where  there  are  large  areas  of  open  space. 
The  compression  standard  specified  by  MIL-R-28002B  for  these  types  of  file  formats  is 
Group  4  encoding  as  defined  by  the  CCITT  Recommendation  T.6,  “Facsimile  Coding 
Schemes  and  Coding  Control  Functions  for  Group  4  Facsimile  Apparatus.” 

a.  Advantages 

The  prime  advantage  of  MIL-R-28002B  is  its  commitment  to  follow 
developments  with  international  standards  and  trends  in  industry.  Whereas  the  origins  of 
this  standard  were  to  fill  a  void  for  requirements  for  handling  large  engineering  drawings, 
the  CALS  Policy  Office  has  resolved  to  work  side-by-side  with  industry  by  forming  a  joint 
Industry/DoD  Tiling  Task  Group.  The  Tiling  Task  Group  is  headed  by  NIST  and 
continues  to  monitor  and  develop  issues  related  to  MIL-R-28002B.  (Gamer,  et.  al.,  1994, 
pg-  5-5) 

b.  Current  Implementations 

This  standardization  document  is  used  in  several  DoD  programs.  The 
Navy  Automated  Document  Management  And  Publishing  System  (ADMAPS)  uses  the 
specification  for  document  scanning,  raster  image  display  and  raster  image  storage.  The 
Air  Force  Engineering  Data  Computer-Assisted  Retrieval  System  (EDCARS)  and  the 
Army  Digital  Storage  and  Retrieval  Engineering  Data  System  (DSREDS)  have  used  the 
MIL— R-28002A  standard  for  Type  I  raster  graphics  files.  These  raster  graphics  files  have 
been  successfully  interchanged  using  MIL-D-1840A  and  displayed  on  the  Engineering 
Data  Management  Information  Control  System  (EDMICS),  now  known  as  Joint  EDMICS 
(JEDMICS).  (Gamer,  et.  al.,  1994,  pp.  5-2,  5-7) 
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c.  Vendor  Support 


Presently,  InterLinear  Technology’s  Modular  Electronic  Document 
Information  Solution  is  the  only  software  application  that  supports  both  MIL-M-28002B 
Type  I  and  II  raster  graphics  files  (Gamer,  et.  al.,  1994,  pg.  5-8). 

2.  Future  of  Standard 

This  standard  is  in  its  third  revision  and  has  been  revised  every  two  years  since 
originally  issued  in  1988.  It  is  anticipated  that  future  revisions  will  follow  international 
standards  developments  and  industry  trends.  The  portions  of  this  standard  relating  to  the 
Group  4  encoding  compression  and  the  ODA  Raster  Document  Application  Profile  will  be 
removed  once  they  are  incorporated  by  NIST  into  FIPS  publications. 

D.  MIL-D-28003A 

This  standardization  document  was  developed  for  the  DoD  by  NIST  in 
coordination  with  several  industry  groups.  Titled,  “Digital  Representation  for 
Communication  of  Illustration  Data;  Computer  Graphics  Metafile  (CGM),”  this  standard 
is  used  when  graphics  or  illustrations  are  interchanged  between  two  systems  in  binary 
form. 


1.  Purpose  aud  Applicability 

The  CGM  standard  is  published  by  the  ISO  (ISO/IEC  8632),  the  ANSI 
(ANSI/ISO  8632.1-4:1992),  and  the  federal  government  (FIPS  PUB  128)  and  defines  the 
lowest  level  of  drawing  functionality  required  to  reproduce  a  picture  with  a  drawing 
application.  Being  a  standard,  CGM  is  defined  to  be  independent  of  specific  hardware 
platforms  and  software  applications.  A  metafile  is  created  by  a  drawing  application 
generator  and  contains  the  information  required  for  the  picture  data  for  the  file.  If  the  file 
is  imported  into  a  second  drawing  application  an  interpreter  reads  the  information  so  that 
it  may  work  with  the  file.  To  accommodate  a  variety  of  existing  drawing  applications,  the 
CGM  standard  intentionally  only  specifies  the  output  primitives  and  attributes  and  does 
not  specify  the  semantics  for  picture  data.  This  creates  the  requirement  for  an  Application 
Profile.  (Gamer,  et.  al.,  1994,  pg.  6-1) 
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With  MIL-D-28003A,  the  DoD  has  defined  how  CGM  files  should  be  used  with 
CALS  applications.  The  Application  Profile  defines  rules  for  the  generator  and  interpreter 
for  a  drawing  application  that  seeks  compatibility  with  the  CALS  initiative.  Although 
illustration  data  files  can  be  interchanged  in  text,  character  and  binary  formats,  this 
standard  only  approves  the  use  of  binary  format  for  the  encoding  of  CGM  files.  (Gamer, 
et.  al.,  1994,  pg.  6-2) 

a.  Advantages 

The  primary  advantage  of  this  standard  is  its  independence  from  particular 
hardware  platforms  such  as  monitors,  printers,  plotters,  cameras,  and  software 
applications  such  as  drawing  and  publishing  applications.  CGM  is  considered  to  be  the 
best  format  for  illustration  data  when  compared  to  raster  (larger  size  and  dependence  on 
the  resolution  of  the  output  device)  and  2D  IGES  (larger  size  and  slower  speed).  (Gamer, 
et.  al.,  1994,  pg.  6-6) 

b.  Vendor  Support 

This  standard  with  its  Application  Profile  is  considered  a  subset  of  the 
international  and  national  CGM  standard.  Many  vendors  that  claim  CGM  standard 
conformance,  do  not  conform  with  MIL-D-28003A  because  of  the  lack  of  the  Application 
Profile  details  necessary  for  use  with  CALS  applications.  Currently  six  software  vendors 
(Ashton-Tate,  Computer  Support,  Lotus  Development,  Micrografx,  Hewlett-Packard,  and 
Software  Publishing)  offer  applications  that  can  both  import  and  export  CGM  files 
conforming  to  MIL-D-28003A.  Numerous  other  vendors  offer  applications  that  can 
either  import  or  export  CGM  files  or  can  both  import  and  export  CGM  files,  but  only  in 
conformance  with  the  previous  version  of  this  specification.  DoD  organizations  planning 
to  use  a  drawing  application  for  CALS  compliant  illustrations  should  be  certain  that  the 
application  explicitly  conforms  with  the  import  and  export  requirements  of  MIL-D- 
28003 A.  (Gamer,  et.  al.,  1994,  pp.  6-8,  6-9) 

2.  Future  of  Standard 

This  standard  was  first  issued  in  1988  and  is  currently  in  its  first  revision  (1991) 
with  amendment  1  (1992).  A  possible  evolution  of  the  CGM  standard  in  the  CALS 


42 


environment  is  the  definition  of  “intelligent  graphics.”  This  type  of  graphic  will  contain 
information  related  to  the  graphic,  but  not  pertaining  to  the  illustration  itself  For 
example,  the  requirement  for  attaching  comments  about  the  graphic  with  the  illustration 
and  version  control  information  for  the  illustration  could  be  attached  to  a  graphic  file 
through  the  use  of  SGML  tags  on  the  illustrations.  (Gamer,  et.  al.,  1994,  pg.  6-6) 

The  international  CGM  standard  is  planning  to  specify  three  different  widely  used 
application  profiles  (including  the  MIL-D-28003A  Application  Profile)  in  its  next  revision 
(Gamer,  et;  al.,  1994,  6-4).  This  may  alleviate  the  need  for  this  standard  if  the 
international,  national  and  federal  CGM  standards  cover  all  the  CALS  specific  illustration 
requirements. 

E.  CALS  TEST  NETWORK 

The  CALS  Test  Network  (CTN)  is  an  Air  Force  managed  program  used  to 
perform  testing  of  CALS  standards  and  CALS  implementations.  CTN  tests  are  performed 
by  DoD  and  industry  representatives  at  various  testbeds  at  military  laboratories  and 
national  laboratories.  The  results  are  published  on  the  CALS  Bulletin  Board  System 
(BBS)  for  review.  The  primary  aim  of  these  tests  is  to  “demonstrate  the  CALS  standards, 
test  their  effectiveness  and  identify  needed  improvements  to  the  standards.  Most  of  the 
current  work  to  data  on  the  CTN  has  been  on  data  interchange  standards,  such  as  MIL- 
STD-1840A  “Automated  Interchange  of  Technical  Information.”  (Navy  CALS  RIC 
DTG,  1994,  pg.  12-12) 

The  next  chapter  describes  the  Evolved  Seasparrow  Missile  Program  and  its 
application  of  the  CALS  initiative  specifications  and  standards  in  the  first  contract  of  the 
weapon  system  program. 
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IV.  EVOLVED  SEASPARROW  MISSILE  PROGRAM 


This  chapter  describes  the  Evolved  SEASPARROW  Missile  (ESSM)  program. 
The  ESSM  is  an  upgrade  of  the  RIM-7P  SEASPARROW  missile  with  added  capabilities 
to  counter  anti-ship  cruise  missiles  that  have  maneuvering  capabilities.  Background 
material  on  the  weapon  system  is  presented  first,  followed  by  a  description  of  how  the 
ESSM  program  office  has  applied  the  Continuous  Acquisition  and  Life-cycle  Support 
(CALS)  initiative  during  the  acquisition  planning  process.  The  chapter  concludes  with  a 
description  of  the  solicitation  and  source  selection  process  for  the  first  contract  for  the 
ESSM  program:  the  Engineering  and  Manufacturing  Development  (EMD)  Phase 
contract. 

A.  BACKGROUND 

This  section  provides  background  material  on  the  ESSM.  It  includes  a  description 
of  the  weapon  system,  a  description  of  the  program  participants,  and  a  description  of  the 
program  schedule. 

1.  Weapon  System  Description 

The  original  RIM-7  SEASPARROW  missile  programs  for  surface  ships  were 
outgrowths  of  the  Naval  Air  Systems  Command  (NAVAIR)  air-to-air  SPARROW  missile 
program.  These  programs  included  the  Basic  Point  Defense  Missile  System  (BPDMS), 
which  employed  the  RIM-7M  missile  and  the  follow-on  SEASPARROW  missile  system. 
This  missile  system  later  became  known  as  the  North  Atlantic  Treaty  Organization 
(NATO)  SEASPARROW  Missile  System  (NSSMS),  employing  the  RIM-7P  missile. 
These  weapon  systems,  while  effective  at  first,  were  unable  to  keep  pace  with  recent 
developments  in  anti-ship  cruise  missile  technology. 

The  ESSM  is  a  surface-to-air  missile  that  is  launched  from  surface  ships  against 
incoming  anti-ship  cruise  missiles  with  maneuvering  capabilities.  An  enhancement  of  the 
RIM-7P  missile,  the  ESSM  will  have  improvements  in  its  rocket  motor,  tail  control 
surfaces,  improved  guidance  section,  and  an  upgraded  warhead. 
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2.  Program  Participants 


This  section  describes  the  ESSM  program  participants  within  the  DoN,  allied 
nations,  and  potential  contractors. 

a.  Department  of  the  Navy 

As  stated  previously,  the  SEASP ARROW  missile  system  was  originally  a 
NAVAIR  program  within  the  Department  of  Navy  (DoN).  The  ESSM,  however,  will  be  a 
Naval  Sea  Systems  Command  (NAVSEA)  program  within  the  Theater  Air  Defense  (TAD) 
Program  Executive  Office  (PEO).  Because  portions  of  the  RIM-7P  missile  will  be  used  in 
the  ESSM,  configuration  management  and  legacy  technical  data  issues  will  need  to  be 
coordinated  between  NAVAIR  Tactical  Air  PEO  and  the  ESSM  program  office. 

Outside  NAVSEA,  several  other  DoN  activities  will  have  roles  and 
responsibilities  in  the  ESSM  program.  These  DoN  activities  are  listed  below; 

•  The  Naval  Air  Warfare  Center  Weapons  Station  at  China  Lake,  CA  will  be  the 
Technical  Director  Activity  and  Source  Selection  Activity.  It  will  be 
responsible  for  all  technical  aspects  of  the  ESSM  and  will  select  the  defense 
contractor  for  the  ESSM. 

•  Port  Hueneme  Division,  Naval  Surface  Warfare  Center  (PHD-NSWC),  Port 
Hueneme,  CA  will  be  the  In-Service  Support  Engineering  Agent  (ISEA)  and 
the  Testing  and  Evaluation  (T  &  E)  Agent.  As  the  ISEA,  PHD-NSWC  will  be 
responsible  for  receiving  any  technical  data  associated  with  the  program  and 
distributing  it  to  the  other  government  program  participants.  It  will  also  be  the 
repository  for  technical  data  and  program  documentation  for  the  life-cycle  of 
the  weapon  system.  As  the  T&E  Agent,  PHD-NSWC  will  coordinate  and 
conduct  development,  live-firing,  operational,  certification  testing,  as  well  as 
evaluation  for  the  ESSM. 

•  Dahlgren  Division,  Naval  Surface  Warfare  Center,  Dahlgen,  VA  will  be  the 
Principal  for  Safety.  It  will  be  responsible  for  developing  handling  and  storage 
and  usage  safety  procedures  for  the  ESSM  and  reviewing  contractor  delivered 
safety  documentation. 

b.  ESSM  Allied  Nations 

The  SEASP  ARROW  missile  program  has  been  exported  to  eleven  allied 

North  Atlantic  Treaty  Organization  (NATO)  countries  and  Australia  through  the  Foreign 
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Military  Sales  (FMS)  program.  These  nations  became  known  as  the  NATO 
SEASP ARROW  Consortium. 

The  ESSM  program  will  differ  from  the  NATO  SEASP  ARROW  missile 
program  in  that  participating  nations  and  defense  contractors  in  their  nations  will  share  in 
the  development  and  manufacturing  of  the  weapon  system  in  a  workshare  effort.  The 
United  States’  defense  contractor  who  will  act  as  the  prime  contractor  will  be  responsible 
for  the  design  and  manufacture  of  the  guidance  and  the  warhead  sections  as  well  as  the 
integration  of  the  entire  missile.  The  allied  defense  contractors  will  develop  and 
manufacture  the  kinematic  upgrades  of  the  rocket  motor  and  tail  control  section. 

These  nations  (Australia,  Canada,  Denmark,  Germany,  Greece,  The 
Netherlands,  Norway,  Portugal,  Spain,  and  Turkey)  have  formed  an  ESSM  Steering 
Committee  that  will  meet  semi-annually  to  review  progress  on  the  weapon  system 
program.  Additionally,  these  nations  will  share  in  the  costs  of  the  program  beginning  in 
fiscal  year  1995.  They  will  provide  military  and  civilian  defense  acquisition  personnel  to 
the  ESSM  program  office. 

c.  Potential  Contractors 

With  the  shrinking  of  the  US  defense  industrial  base,  there  are  presently 
only  two  potential  defense  contractors  with  the  capability  to  deliver  a  weapon  system  such 
as  the  ESSM.  These  contractors  are  Hughes  Missile  Systems  Company  in  Tucson,  AZ 
and  Raytheon  Company,  Missile  Systems  Division  located  in  Tewksbury,  MA. 

3.  Program  Schedule 

The  ESSM  program  schedule  for  the  EMD  Phase  contract  is  expected  to  be 
awarded  in  the  May- June  1995  time  frame.  The  EMD  contract  encompasses  the  delivery 
of  technical  data  packages,  analysis  and  test  reports,  and  an  in-service  support  engineering 
package.  It  also  includes  production  representative  All  Up  Round  (AUR)  missiles  of  the 
upgraded  RIM-7P  missile  for  conduct  of  developmental  and  operational  testing.  The 
contract  also  specifies  the  delivery  of  the  MK  41  Vertical  Launch  System  (VLS)  Quad- 
Pack  Canister.  This  is  a  specially  designed  container  that  will  hold  four  ESSMs  for  DDG 
51,  Flight  II A  ships. 
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Following  design  reviews  scheduled  in  1996,  the  delivery  of  the  first  test  article  is 
expected  in  the  first  quarter  of  1997.  Development  and  certification  testing  will  begin  in 
the  forth  quarter  of  1995  and  continue  into  the  next  century. 

Following  successful  development  testing  of  the  ESSM  and  receipt  of  Secretary  of 
the  Navy  approval  for  acquisition  milestone  III  (which  is  projected  to  occur  in  May  1999) 
it  is  expected  that  the  EMD  phase  contract  will  be  modified  for  a  Low-Rate  Initial 
Production  (LRIP)  Contract  (approximately  200  missiles)  and  eventually  a  Full-Rate 
Production  (FRP)  Contract  (4,355  missiles).  The  LRIP  and  FRP  contracts  will  be 
subjected  to  competitive  bidding. 

B.  ESSM  ACQUISITION  PLANNING  PROCESS 

This  section  describes  the  Evolved  SEASP ARROW  Missile  Program  Executive 
Office’s  Continuous  Acquisition  and  Life-cycle  Support  (CALS)  Government  Concept  of 
Operations  and  Data  Management  Plan  for  technical  data.  These  documents  will  comprise 
two  of  the  annexes  to  the  ESSM  Master  Program  Plan  (MAPP).  The  MAPP  will  be 
presented  to  the  prime  contractor  in  mid- 1995  as  Government  Furnished  Information 
(GFI)  following  award  of  the  ESSM  EMD  phase  contract. 

1.  Government  Concept  of  Operations 

The  ESSM  Program’s  Government  Concept  of  Operations  (GCO)  document  is 
still  in  a  draft  version  as  of  January  1995.  Its  highlights  are  detailed  below. 

fl.  Scope  and  Applicability 

This  GCO  is  intended  for  use  by  the  prime  contractor  and  any  subsystem 
contractors  in  the  ESSM’s  preliminary  design,  engineering  and  specification  design,  and 
detail  design.  It  applies  to  all  technical  data  and  information  created  by  the  contractors 
and  the  government  during  the  life-cycle  of  the  ESSM  program.  The  GCO  is  provided  as 
government  furnished  information  (GFI)  to  potential  offerors  as  guidance  for  the 
development  of  CALS  capabilities. 
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h.  Goals  and  Objectives 

The  ESSM  program  office  intends  to  acquire  and  manage  data  and 
information  associated  with  the  ESSM  in  digital  formats  in  accordance  with  the  CALS 
strategies.  To  transition  the  ESSM  program  toward  the  CALS  vision,  nations 
participating  in  the  program  must  adhere  to  the  following  goals  and  objectives: 

•  Employ  Concurrent  Engineering  (CE)  principles  to  create  and  store  data  once 
for  use  in  many  applications,  thereby  reducing  development  cycles  and 
increasing  efficiency; 

•  Designate  a  single  point  of  control  for  creation  and  maintenance  of  technical 
data  that  will  be  common  to  multiple  users  thus  increasing  quality,  accuracy, 
and  consistency  of  information;  and 

•  Use  an  integrated  data  base  to  provide  seamless,  automated  access  and 
interchange  of  data  and  information  associated  with  the  ESSM  Program  and 
participating  defense  industry  users. 

c.  Contractor's  Approach  to  CALS 

The  GCO  details  what  information  will  be  required  in  the  Contractor’s 
Approach  to  CALS  (CAC).  Along  with  the  information  specified  in  MIL-HDBK-59B,  the 
ESSM  Program  Office  requested  that  several  specific  issues  be  addressed  in  the  CAC. 
These  issues  were: 

•  How  an  enterprise  environment  can  be  developed  between  the  contractor  and 
his  subcontractors,  suppliers,  and  vendors; 

•  Determination  of  access  rights,  limitations,  and  responsibilities  for  CALS  data 
and  products  among  the  contractor,  subcontractors,  and  the  Government; 

•  Provision  for  the  contractor’s  CE  approach  (that  integrates  system  engineering, 
design,  manufacturing,  and  logistic  support  functions).  Where  information  is 
required  to  be  transferred  among  functional  areas,  key  fimctional  and  data 
relationships  between  processes  should  be  identified  and  discussed;  and 

•  A  description  of  the  infrastructure  required  to  support  the  CE  environment  that 
generates,  stores  and  delivers  the  weapon  system  data  and  information. 
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2. 


Data  Management  Plan 


The  ESSM  program’s  Data  Management  Plan  (DMP)  is  in  draft  form  as  of 
Januaiy  1995,  specific  details  on  the  DMP  in  its  current  form  are  presented  below. 

a.  Scope  and  Applicability 

The  DMP  documents  how  the  Government  intends  to  process  and  manage, 
in  digital  formats,  the  technical  data  and  information  associated  with  ESSM  program.  It 
defines  the  roles  and  responsibilities  of  Department  of  Navy  activities  participating  in  the 
ESSM  program  and  how  they  will  interface  with  other  program  participants.  Details  of 
the  DMP  are  applicable  to  all  entities  that  develop  and  provide  data  and  information  for 
the  ESSM. 


b.  Data  Management  Organization 

Overall  responsibility  for  data  management  of  the  ESSM  Data 
Management  Plan  rests  vwth  the  NATO  SEASPARROW  Project  Office  Support 
Engineering  Manager  (SEM).  This  office  coordinates  the  generation  of  any  ESSM 
technical  data  and  is  be  responsible  for  the  planning  and  management  of  its  use.  The  SEM 
is  also  responsible  for  supervising  the  development  of  technical  manuals  for  the  ESSM. 

Port  Hueneme  Division,  Naval  Surface  Warfare  Center  (PHD-NSWC) 
Code  4R  (Missile  Systems  Department)  is  designated  the  Data  Manager  for  the  ESSM 
program.  It  is  responsible  for  development,  implementation  and  maintenance  of  a 
technical  data  management  system  that  will  be  able  to  handle  ESSM  techmcal  data  in 
digital  formats.  PHD-NSWC  Code  4R,  as  the  Data  Manager,  is  responsible  for  entering 
all  technical  data  received  from  the  prime  contractor  and  distributing  it  electronically  to 
the  various  DoN  activities  participating  in  the  program  for  comment.  PHD-NSWC  Code 
4R  vidll  also  serve  as  the  repository  for  technical  data  and  ESSM  documentation  for  the 
program.  Code  5B  (Information  Technology  Department)  of  PHD-NSWC  is  designated 
to  provide  technical  support  to  accomplish  this  responsibility. 

c.  Program  Data  Management 

The  DMP  indicates  that  the  Integrated  Data  Management  System  (IDMS) 
will  be  used  during  the  detail  design  stage  of  the  EMD  Phase  of  the  program  and  is 
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planned  to  be  used  during  the  transition  to  production  and  support  phases  of  the  program. 
Specific  details  on  how  the  IDMS  will  be  used  is  presented  in  the  next  chapter. 

d.  Data  Responsibility 

The  DMP  contains  an  ESSM  Data  Responsibility  Matrix  that  identifies 
data  types  in  the  following  categories:  Support  Engineering  Plans  and  Reports;  Support 
Engineering  Data/Summary,  System  Engineering  Plans  and  Reports;  Government 
Furnished  Equipment  Program  Management/Contract  Status;  Financial  Planning;  and 
Conference  Agenda/Minutes.  Within  each  of  these  data  type  categories  a  variety  of 
program  documents  are  listed  by  Contract  Data  Requirements  List  (CDRL)  number.  Each 
of  these  documents  are  coded  with  one  or  more  of  the  responsible  DoN  activities 
associated  with  the  ESSM  Program  indicating  whether  that  activity  has  “view  only,” 
“comment/annotate,”  or  “recommendations/consolidation”  responsibility.  This  matrix  also 
lists  the  office  code  within  the  Project  Office  that  has  the  final  approval  authority  for  a 
particular  document.  A  typical  document  might  be  “view  only  by  one  to  two  activities, 
“comment/annotate”  by  six  to  eight  activities,  and  “recommendations/consolidation”  by 
one  of  the  “comment/annotate”  activities.  The  “comment/annotate”  activity  is  usually 
either  Naval  Air  Warfare  Center  Weapons  Station  at  China  Lake,  CA  for  documents 
relating  to  technical  issues;  Port  Hueneme  Division  Naval  Surface  Warfare  Center  for 
documents  relating  to  testing,  logistics,  and  configuration  issues;  Dahlgren  Division  Naval 
Surface  Warfare  Center  for  documents  relating  to  safety  issues;  or  the  ESSM  Program 
Office  for  documents  relating  to  financial  planning  and  program  management. 

C.  ESSM  SOLICITATION  AND  SOURCE  SELECTION  PROCESS 

This  section  describes  the  CALS  specifications  and  standards  that  are  part  of  the 
ESSM  EMD  phase  contract’s  Statement  of  Work  (SoW).  It  concludes  with  descriptions 
of  certain  line  items  within  the  SoW  relevant  to  the  CALS  initiative. 

It  is  important  to  note  the  ESSM  EMD  phase  contract  Request  for  Proposal  (RFP) 
fell  within  the  180  day  “grace  period”  following  the  Secretary  Perry’s  memorandum 
“Specifications  &  Standards  -  A  New  Way  of  Doing  Business.”  This  ‘  grace  period 
permitted  the  waiver  of  the  implementation  of  the  policy  changes  for  on-going  solicitations 
or  contracts.  (DoD  OSD,  1994,  pg.  2) 
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The  effects  of  the  acquisition  policy  changes  were  evaluated  by  the  ESSM 
Program  Manager  (PM).  The  decision  was  made  to  either  alter  the  wording  of  the  SoW 
where  it  called  for  the  application  of  the  CALS  specifications  and  standards  or  request  a 
two-year  waiver  for  the  use  of  the  CALS  military  specifications  and  standards.  These 
subtle  changes  in  wording  and  the  request  for  a  waiver  are  detailed  with  the  description  of 
the  pertinent  CALS  specification  or  standard. 

1.  ESSM  Specifications  and  Standards 

The  ESSM  program  in  concert  with  the  Navy  Standards  Improvement  Program 
has  a  goal  to  minimize  the  use  of  military  specifications  and  standards  if  suitable 
commercial  standards  are  available.  The  PM  identified  nearly  100  specifications  and 
standards  applicable  to  a  weapon  system  acquisition  such  as  the  ESSM.  In  an  effort  to 
use  performance  specifications  instead  of  military  specifications  and  in  an  effort  to  reduce 
contract  oversight  responsibilities,  the  PM  deleted  23  military  specifications  and  standards 
and  used  31  commercial  standards.  This  left  43  existing  military  specifications  and 
standards  pertaining  to  the  ESSM.  These  43  military  specifications  and  standards  are 
related  to  the  predecessor  RIM-7P  missile  (11),  ordinance  safety  (9),  missile  testing  (6), 
and  miscellaneous  (17),  including  eight  CALS  military  specifications  and  standards. 

The  ESSM  EMD  contract’s  SoW  identifies  eight  CALS  specifications  and 
standards.  These  CALS  specifications  and  standards  can  be  fiirther  categorized  as  CALS 
Standards,  CALS  Data  Format  Specifications  and  Product,  Process,  Data  Integration 
Standards.  Each  of  these  categories  are  explained  in  greater  detail  below. 

a.  CALS  Standards 

CALS  standards  are  two  military  standards  intended  to  facilitate  digital 
data  interchange  between  the  government  and  a  contractor.  These  standards  require  the 
contractor  to  provide  technical  data  to  the  acquisition  managers  Avithout  linking  it  to  a 
proprietary  hardware  platform  or  information  system.  These  standards  are  described  in 
further  detailed  below. 


(1)  MIL-STD-974,  Contractor  Integrated  Technical  Information 
Services  (CITIS).  This  standard  defines  how  a  contractor  is  to  provide  the  government 
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online  access  to  technical  data  related  to  a  government  contract.  The  standard  provides 
guidelines  that  the  contractor  must  follow  for  updating,  storing,  controlling,  reproducing 
and  distributing  the  digital  data  on  CITIS.  (DoD  CALS  &  EDI  Office,  1994,  pg.  25) 

(2)  MIL-STD-1840B,  Automated  Interchange  of  Technical 
Information.^  This  standard  defines  digital  formats  that  may  be  used  by  the  contractor  in  a 
CALS  environment  when  providing  technical  data  to  the  government.  Useful  for  the 
exchange  of  technical  manuals,  engineering  drawings  and  other  digital  data,  it  addresses 
how  users  in  two  different  computer  hardware  and  software  environments  may  share 
technical  data.  This  standard  provides  specific  guidance  on  file  sets  and  formats,  data  file 
representation  standards,  and  file  naming  conventions,  as  well  as  standard  header 
information  for  file  exchange.  Although  the  example  in  the  standard  uses  a  nine-track 
magnetic  tape  for  interchange  media,  the  standard  permits  the  government  and  its 
contractor  to  select  a  mutually  agreeable  interchange  media.  Typical  interchange  media 
includes  mini-cartridge  magnetic  tape  or  optical  storage  disk  and  depends  on  the  computer 
infrastructure  and  technical  data  interchange  requirements  for  the  program  participants. 
(DoD  CALS  &  EDI  Office,  1994,  pg.  25) 

b.  CALS  Data  Format  Specifications 

The  CALS  Data  Format  Specifications  establish  the  requirements  for  the 
delivery  of  technical  data  to  the  government.  Applicable  for  the  delivery  of  vector 
graphics,  ASCII  text,  raster  image  data,  and  graphics  metafiles,  these  specifications  are 
commonly  known  as  the  “28000  series  specs.”  The  specifications  were  discussed  in  detail 
within  Chapter  III,  “CALS  Data  Format  Specifications,”  and  are  listed  below: 

•  MIL-D-28000A(1),  Digital  Representation  for  Communication  of  Product 

Data;  Initial  Graphics  Exchange  Specification  (IGES)  Applications  Subsets 
and  Application  Protocols; 


^The  reader  should  note  that  this  standard  was  not  included  in  the  ESSM  EMD  Contract’s  SoW,  but  was 
presented  here  to  provide  a  complete  description  of  the  two  CALS  standards. 
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•  MIL-M-28001B,  Markup  Requirements  and  Generic  Style  Specification  for 
Electronic  Printed  Output  and  Exchange  of  Text  (SGML); 

•  MIL-R-28002B,  Requirements  for  RASTER  Graphics  Representation  in 
Binary  Format;  and 

•  MIL-D-28003 A(  1 ),  Digital  Representation  for  Communication  of  Illustration 
Data:  CGM  Application  Profile. 

c.  Product,  Process,  Data  Integration  Standards 

Product,  Process,  Data  Integration  Standards  are  intended  to  foster  an 
environment  of  integrated  design,  development  and  manufacturing  where  contractor 
entities  can  work  together  sharing  the  same  technical  data.  These  concepts  are  the  core  of 
the  CALS  initiative.  It  is  left  to  the  acquisition  manager  to  structure  a  contract  to 
encourage  the  contractor,  through  the  use  of  incentives,  to  meet  these  goals  while  fulfilling 
the  contract  requirements.  These  standards  are  described  in  further  detail  below: 

(1)  MIL-STD-499A,  Engineering  Management  (Systems 
Engineering).  This  standard  provides  a  basis  for  defining,  performing,  managing,  and 
evaluating  systems  engineering  processes  related  to  defense  systems  acquisitions.  Related 
to  the  fields  of  concurrent  engineering,  integrated  product  development  and  integrated 
process  development,  this  standard  requires  a  contractor  to  consider  life-cycle  support 
processes  while  developing  a  system  for  defense  procurement.  (DoD  CALS  and  EDI 
Office,  1994,  pg.  27) 

(2)  MIL-STD-973(2),  Configuration  Management  (CM).  This 
standard  requires  consistent  CM  practices  by  a  contractor  when  developing  a  system  for 
defense  procurement.  (DoD  CALS  and  EDI  Office,  1994,  pg.  27)  The  ESSM  PM  has 
requested  and  received  a  two-year  waiver  from  the  Milestone  Decision  Authority  in  order 
to  apply  this  military  standard  to  the  ESSM  EMD  phase  contract. 


54 


(3)  MIL-STD-1388-1A(4)  and  ]VI1L-STD-1388-2B(1),  Logistic 

Support  Analysis  Record  (LSAR)  and  DoD  Requirements  for  a  LSAR.  The  LSAR 
standard  requires  contractors  to  simultaneously  perform  Logistic  Support  Analysis  during 
the  development  of  a  defense  system.  This  standard  strives  to  give  the  DoD  a  unified 
method  to  require  contractors  to  (a)  make  support  requirements  a  critical  part  of  the 
defense  system  design,  (b)  specify  what  the  support  requirements  will  be  as  related  to  the 
system  design,  (c)  define  what  the  support  requirements  will  be  when  the  system  is  used 
operationally,  and  (d)  design  and  provide  requirement  support  material  for  the  defense 
system.  MIL-STD-1388-2B(1)  defines  how  the  LSAR  data  should  be  delivered  so  that  it 
may  incorporated  into  manual  logistic  data  and  Automated  Data  Processing  (ADP) 
systems.  (DoD  CALS  and  EDI  Office,  1994,  pp.  27-28)  The  ESSM  PM  with  the  new 
acquisition  policy  phrased  the  SoW  language  as  “use  the  guidance  of  MIL-STD-1388- 
1A(4)  and  MIL-STD-1388-2B(1)”  instead  of  directly  requesting  that  the  contractor 
adhere  to  the  military  standards.  This  nuance  encourages  the  contractor  to  follow  the 
military  standard  without  specifically  requiring  him  to  apply  the  military  standard. 

2.  STATEMENT  OF  WORK 

This  section  provides  details  in  the  ESSM  EMD  phase  contract  RFP’s  SoW  on 
technical  data  and  documentation  and  technical  publishing  related  line  items. 

a.  Contractor  Integrated  Technical  Information  Services  (CITIS) 

The  ESSM  PM  is  committed  to  conducting  this  weapon  system  acquisition 
within  the  requirements  of  the  CALS  initiative.  The  Contractor  Integrated  Technical 
Information  Services  (CITIS)  is  a  database  located  at  the  contractor  site  that  may  be 
accessed  by  authorized  acquisition  management  and  technical  oversight  personnel  of  the 
federal  government.  The  definition  of  the  telecommunications  solution  for  the  CITIS  is 
requested  to  be  in  accordance  with  the  CITIS  CALS  standard  (MIL-STD-974)  and  the 
Government  Open  System  Interconnect  Protocols  (GOSIP)  contained  in  FIPS  PUB  146- 
1. 
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b.  Technical  Manual  Program 

The  technical  documentation  for  the  ESSM  EMD  phase  contract  is  to 
include  three  technical  manuals;  Theory  of  Operations  Manual,  ESSM  Functional 
Description  Manual,  and  Explosive  Ordnance  Disposal  Manual.  These  manuals  shall  be 
developed  under  the  requirements  of  the  Technical  Manual  Contract  Requirement 
(TMCR)  and  the  CALS  requirements.  Additionally,  the  contractor  is  required  to  provide 
the  source  data  required  to  update  the  technical  documentation  associated  with  Fire 
Control  and  Launcher  Systems  technical  manuals  that  will  be  affected  by  the  ESSM. 

This  chapter  has  presented  an  overview  of  the  ESSM  program  including 
specific  details  of  how  the  ESSM  program  office  applied  the  CALS  initiative  during  the 
acquisition  planning  processes  and  source  selection  processes.  The  next  chapter  will 
present  the  information  technology  inffastrupfure  available  for  management  of  ESSM 
technical  data  at  PHD-NSWC,  the  Navy’s  ISE4  for  surface  ship  weapon  systems. 
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V.  INFORMATION  TECHNOLOGY  INFRASTRUCTURE  AT  THE  IN- 
SERVICE  SUPPORT  ENGINEERING  AGENT 

This  chapter  presents  the  information  technology  infrastructure  at  the  In-service 
Support  Engineering  Agent  (ISEA)  for  the  ESSM  program.  Port  Hueneme  Division, 
Naval  Surface  Warfare  System  (PHD-NSWC)  has  been  designated  the  ISEA  by  the 
ESSM  program  office.  This  makes  it  responsible  for  numerous  tasks  relating  to 
maintenance  of  the  technical  data  for  the  ESSM  during  the  life-cycle  of  the  weapon 
system.  As  stated  in  Chapter  IV,  PHD-NSWC,  in  its  role  as  the  ISEA,  will  be  the  Data 
Manager  during  the  procurement  phases  of  the  missile  system. 

The  information  technology  (IT)  infrastructure  and  the  information  systems 
available  at  PHD-NSWC  will  be  crucial  factors  in  how  well  PHD-NSWC  will  be  able  to 
perform  its  role  as  the  Data  Manager  for  the  ESSM  Program.  The  ESSM  Program 
Office’s  objective  is  to  acquire  and  manage  technical  data  and  documentation  associated 
with  the  ESSM  in  digital  formats  in  accordance  with  the  CALS  strategies.  PHD-NSWC 
will  thus  be  a  proving  ground  for  the  CALS  principals. 

The  Integrated  Data  Management  System  (IDMS),  an  information  system  that 
allows  users  to  access  and  process  many  types  of  technical  data  on  integrated  technical 
databases  from  a  common  computer  desktop  environment,  is  presented  first.  Then  a 
description  of  how  portions  of  the  Joint  Computer-aided  Acquisition  and  Logistics 
Support  (JCALS)  System  are  planned  to  be  integrated  with  the  IDMS  to  form  a  more 
capable  data  management  system  is  presented. 

A.  INTEGRATED  DATA  MANAGEMENT  SYSTEM 

The  Integrated  Data  Management  System  (IDMS)  originates  from  an  information 
system  designed  to  manage  ordnance  alteration  (ORDALT)  instructions  and  Engineering 
Change  Proposals  (ECPs)  at  PHD-NSWC.  The  development  for  this  system,  named  the 
Automated  Documentation  System  (ADS),  began  in  1988  and  was  funded  by  Naval  Sea 
Systems  Command  (NAVSEA)  Productivity  Investment  Funds.  During  the  development 
and  testing  of  ADS,  a  determination  was  made  that  ADS  technology  could  be  adapted  to 
Technical  Manual  (TM)  change  processes.  A  second  ADS  was  procured  by  PHD-NSWC 
and  parallel  development  began  for  integration  of  a  technical  manual  processing 
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functionality.  During  the  subsequent  development  of  the  two  ADSs,  a  number  of 
similarities  between  the  two  efforts  were  identified.  This  resulted  in  the  decision  to 
combine  the  two  development  efforts.  The  two  systems,  with  the  addition  of  a  software 
module  to  manage  Contract  Data  Requirements  List  (CDRL)  in  1992,  were  renamed  the 
Integrated  Data  Management  System  (IDMS).  Development  and  implementation 
responsibilities  for  DDMS  were  consolidated  at  PHD-NSWC  Code  5B00  (Technical  Data  - 
now  Information  Technology  Department).  A  fully  operational  IDMS  was  developed  by 
Scientific  Applications  International  Corporation  (SAIC)  and  the  system  has  been 
operational  since  1993.  Version  2.1  is  the  current  version.  A  second  phase  for  IDMS 
development  is  planned  with  added  functionality  and  further  integration  with  other 
information  systems. 

1.  System  Design 

IDMS’  software  applications  have  been  integrated  using  a  three-layer  architecture 
concept.  The  inner-most  layer  is  considered  the  system  layer,  consisting  of  the  operating 
system  and  network  management  utilities.  The  middle  layer  is  the  support  layer.  It  is 
comprised  of  six  application  components;  (1)  the  Visual  Programming  Environment,  (2) 
the  Interface  Manager,  (3)  the  System  Adnunistration  Manager,  (4)  the  Electronic  Mail 
and  Bulletin  Manager,  (5)  the  Technical  Publishing  System,  and  (6)  the  Report  Manager. 
The  outer-most  layer  represents  the  application  layer.  It  consists  of  the  following  nine 
user  functions:  (1)  Document  Manager,  (2)  Distributed  Software  Backplane,  (3)  Report 
Generation,  (4)  System  Administration,  (5)  Tracking,  (6)  Review  and  Edit,  (7)  Review 
and  Comment,  (8)  Graphical  User  Interface,  and  (9)  Electronic  Mail  and  Bulletin 
Interface.  While  helpful  in  understanding  how  IDMS’  applications  are  integrated  in  this 
current  version,  it  is  not  certain  whether  this  three-layer  architecture  will  be  maintained  in 
future  phases  of  IDMS’  development.  (PHD-NSWC  IDMS  User’s  Guide,  1994,  pp.  C- 
12,  C-13) 

2.  System  Configuration 

IDMS  makes  use  of  an  open  system  architecture  to  integrate  commercial  off-the- 
shelf  (COTS)  software  applications  in  a  client-server  environment.  An  object-oriented 
application  development  environment.  Visual  Programming  Environment  (VPE)  by 
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Market  Focus  Technologies,  Inc.,  a  division  of  SAIC,  was  used  to  integrate  IDMS’ 
various  software  applications.  The  remainder  of  this  section  will  describe  IDMS’ 
Hardware  and  Networking  Platform,  Software  Platform,  and  User  Types. 

a.  Hardware  and  Networking  Platforms 

IDMS  consists  of  multiple  servers,  workstations,  and  personal  computers 
(PCs).  The  IDMS  servers  store  a  particular  type  of  document  created  from  within  IDMS 
or  obtained  from  another  source.  They  provide  users  on-line  access  to  a  document 
through  a  client-server  access.  Each  server  is  connected  to  local  area  and  wide  area 
networks,  the  Central  Database  Server,  and  other  IDMS  servers  using  thick  Ethernet 
cabling  and  the  TCP/IP  protocol.  The  Central  Database  Server  allows  other  servers  to 
access  a  central  repository  for  all  the  life-cycle  and  routing  information  for  a  particular 
type  of  document.  IDMS  workstations  are  intended  for  users  with  management 
responsibilities  for  a  particular  type  of  document.  They  permit  users  the  most 
functionality.  An  IDMS  workstation  is  connected  to  the  IDMS  servers  using  thick 
Ethernet  cabling.  IDMS  servers  and  workstations  at  PHD-NSWC  are  either  Hewlett 
Packard  (HP)  9000  series,  or  Sun  Microsystems  SPARCstation  hardware.  A  typical 
IDMS  user  will  access  IDMS  through  a  desktop  PC  using  an  X-terminal  emulation 
software  application.  This  permits  the  user  to  become  a  client  on  one  of  the  IDMS  servers 
and  thus  run  IDMS  applications  on  his  desktop  PC.  A  typical  PC  at  PHD-NSWC  is  a  386 
or  486  IBM  compatible  PC  with  four  to  eight  MegaBytes  (MB)  of  Random  Access 
Memory,  180  or  larger  MB  hard  drive,  fourteen  inch  or  larger  Super  Video  Graphics 
Array  (SVGA)  color  monitor,  Ethernet  adapter  card  for  local  area  access,  and  a  14.4 
Megabit-per-second  (Mbps)  modem  for  wide  area  access.  Figure  3  depicts  the  Integrated 
Data  Management  System  Hardware  and  Network  Platforms. 


59 


Figure  3.  Integrated  Data  Management  System 
h.  Software  Platform 


IDMS  has  been  implemented  as  an  integration  of  the  UNIX  operating 
system  and  the  X-Windows  client-server  environment  with  numerous  commercial  X- 
Window  desktop  applications  and  database  engines.  IDMS  workstations  use  either  the 
HP-UX  or  SunOS  UNIX  operating  systems.  Some  of  the  X-Windows  commercial 
applications  include:  Interleaf  s  Interleaf  5  desktop  publishing  application.  Worldview 
document  interchange  application,  Printerleaf  document  printing  application;  Novell’s 
WordPerfect  5.0  desktop  publishing  application;  and  Xerox  Imaging  System’s  ScanWorX 
document  scanning  application.  The  database  engines  used  in  EDMS  include  Sybase’s 
Relational  Data  Base  Management  System  (RDBMS)  and  Oracle’s  RDBMS,  version  7.X. 

Desktop  PCs  at  PHD-NSWC  that  can  function  as  clients  on  IDMS  use 
Microsoft  DOS  version  6.2  and  Windows  for  Workgroups  version  3.1  for  their  operating 
systems.  The  local  area  network  access  is  provided  by  Novell  NetWare,  which  provides 
File  Transport  Protocol  (FTP),  telnet,  and  E-Mail  capabilities.  The  X-Windows  emulation 
application  for  IDMS  varies  among  the  following  applications:  EXCEEDW,  WQR  X,  or 
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PC  XVIEW.  The  TCP/IP  protocol  stack  for  IDMS  is  either  Microsoft’s  TCP/EP  from 
Windows  for  Workgroups  or  WQR  TCP/IP.  Each  desktop  PC  at  PHD-NSWC  also  has 
an  array  of  single-user  desktop  software  applications  such  as  word  processing, 
spreadsheet,  graphic  presentation  and  drawing  applications.  These  are  selected  according 
to  each  user’s  preference  and  do  not  appear  to  conform  to  any  type  of  standard  set  by  the 
Information  Technology  Department  at  PHD-NSWC. 

c.  User  Types 

IDMS  was  conceived  for  two  types  of  users:  View  and  Edit  users  and 
Review  and  Comment  users.  View  and  Edit  users  are  managers  and  technical  writers  who 
are  responsible  for  editing  technical  documents  such  as  technical  manuals,  technical 
bulletins,  and  advance  change  notices.  These  users  may  create  documents  on  EDMS 
workstations  at  the  central  document  processing  area  and  route  them  to  Review  and 
Comment  users  who  use  their  desktop  PCs  at  their  assigned  work  areas. 

Review  and  Comment  users  are  engineers  and  logisticians  who  review  the 
various  types  of  technical  documents.  These  users  may  not  alter  a  document  that  is  routed 
to  them,  but  they  may  add  their  recommendations  and  comments  to  a  document  by 
attaching  electronic  notes  to  the  document  using  the  Interleaf  Worldview  application.  The 
electronic  notes  are  stored  in  a  local  working  file  and  returned  to  a  View  and  Edit  user 
once  the  document  review  has  been  completed. 

3.  System  Functions 

This  section  describes  the  functionality  of  IDMS  from  the  perspective  of  the  two 
user  types.  The  information  in  this  section  is  taken  from  the  respective  user  guides  for 
EDMS  View  and  Edit  users  and  Review  and  Comment  users. 

a.  Technical  Publishing  System 

The  Technical  Publishing  System  (TPS)  function  of  EDMS  allows  a  View 
and  Edit  user  to  start  either  the  Interleaf  5  or  WordPerfect  5.0  desktop  publishing 
applications.  If  a  View  and  Edit  user  intends  to  route  a  technical  document  for  review,  it 
must  be  processed  by  the  Interleaf  Printerleaf  function  and  it  must  reside  in  an  Interleaf 
Book.  The  Printerleaf  function  prepares  a  print  image  file  for  an  Interleaf  document  that 
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becomes  a  static  copy  of  the  document  and  cannot  be  edited  directly.  The  Interleaf  Book 
function  serves  as  a  filing  cabinet  metaphor  for  storage  of  the  Printerleaf  version  of  the 
technical  document  and  makes  it  accessible  to  other  users  if  necessary.  If  WordPerfect 
documents  need  to  be  routed,  they  are  first  converted  to  Interleaf  format  and  then 
processed  as  discussed  earlier. 

Currently  there  are  no  plans  to  integrate  the  Interleaf  5  <SGML>™  CALS- 
compliant  publishing  system  and  the  associated  CALS-compliant,  SGML-based 
applications  into  IDMS.  The  primary  reason  for  not  pursuing  this  logical  upgrade  for 
DDMS  is  the  refusal  of  Interleaf  to  sell  their  publishing  system  without  PHD-NSWC 
purchasing  their  application  integration  services.  Their  cost  for  this  does  not  seem 
justified.  System  integrators  at  PHD-NSWC  are  capable  and  able  to  perform  the 
integration  of  Interleaf  5  <SGML>™  at  a  more  reasonable  cost.  This  situation  will  mean 
that  IDMS  will  not  receive  a  CALS-compliant  publishing  system. 

b.  Document  Routing  and  Revmv 

The  Document  Routing  System  is  a  custom  application  created  by  SAIC 
that  permits  a  View  and  Edit  user  to  route  a  document  to  Review  and  Comment  Users. 
View  and  Edit  users  may  assign  an  entire  technical  document  or  portions  of  a  technical 
document  to  one  or  more  reviewers,  set  a  due  data  for  the  review,  and  create  a  report  of 
the  workload  for  a  particular  reviewer.  This  application  does  not  contain  any  type  of  true 
workflow  generation  capabilities.  Instead  it  provides  a  simplistic  “out-and-back”  routing 
capability.  The  View  and  Edit  user  is  presented  with  a  list  box  of  potential  groups  and 
individual  users  within  each  process  flow  at  PHD-NSWC.  These  process  flows  include 
ECPs,  ORDALTS,  CDRLs,  and  correspond  to  Interleaf  filing  cabinets.  A  manager  selects 
one  or  more  Review  and  Comment  user(s)  to  whom  the  technical  document  should  be 
routed  according  to  the  process  flow.  This  system  also  allows  a  manager  to  de-route  a 
document  and  alter  the  due  data  for  a  document  that  has  been  routed  to  IDMS  Review 
and  Comment  users. 

The  Review  and  Comment  users  perform  their  functions  by  selecting  the 
Review  button  from  the  IDMS  desktop.  This  act  launches  the  Interleaf  Worldview 
application  that  permits  a  Review  and  Comment  user  to  view  an  Interleaf  document  and 
submit  his  comments  on  the  technical  document  by  attaching  electronic  notes  to  the 
document.  This  is  a  two-step  process  where  the  Review  and  Comment  user  opens  a  blank 
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electronic  note  and  types  his  textual  comments,  then  iconifies  the  electronic  note,  and 
drags  it  to  the  relevant  section  of  the  document. 

c  Contract  Data  Requirements  List  Definition,  Tracking,  and 
Review 

Contract  Data  Requirements  List  (CDRL)  Definition  and  Tracking  are  two 
separate  functions  on  an  IDMS  View  and  Edit  user  desktop.  The  Definition  function 
allows  a  View  and  Edit  user  to  either  create  a  new  CDRL  or  update  an  existing  CDRL.  It 
also  permits  a  user  to  indicate  the  recipients,  types,  and  quantities  of  CDRL  deliverables  in 
the  CDRL  database.  The  Tracking  Function  permits  a  user  to  monitor  the  status  of 
CDRL  items  for  a  selected  contract.  The  CDRL  Review  function  rests  on  a  IDMS 
Review  and  Comment  user  desktop  and  allows  one  to  view  a  “read-only”  CDRL  form  and 
to  attach  comments  using  the  Interleaf  Worldview  application. 

d.  Document  and  CDRL  Comment  Merge 

The  Document  and  CDRL  Comment  Merge  system  permits  a  View  and 
Edit  user  to  incorporate  the  comments  from  Review  and  Comment  users  on  a  technical 
document  or  CDRL.  The  electronic  note  in  Interleaf  Worldview  is  opened  and  a  “cut  and 
paste”  operation  is  performed  onto  the  technical  document  or  CDRL  form  using  either  the 
Technical  Publishing  System  or  CDRL  definition  system,  respectively. 

e.  Return,  Mailbox,  and  Utilities 

The  IDMS  Return  function  permits  a  Review  and  Comment  user  to  return 
a  technical  document  or  CDRL  to  a  View  and  Edit  user  after  completion  of  his  review 
responsibilities.  The  Mailbox  function  provides  standard  E-Mail  capabilities  to  both  types 
of  IDMS  users  and  is  the  primary  method  for  View  and  Edit  users  to  notify  Review  and 
Comment  users  of  a  their  workload.  The  IDMS  Utilities  functions  include  a  calendar 
program,  electronic  calculator,  floppy  disk  utility,  graphical  user  interface  controls, 
password  utility,  and  the  ScanWorX  document  scanning  application. 
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B.  INTEGRATION  OF  IDMS  WITH  JCALS 


This  section  describes  the  planned  effort  to  integrate  the  Integrated  Data 
Management  System  (IDMS)  with  the  Joint  Computer-aided  Acquisition  and  Logistics 
Support  (JCALS)  System. 

1.  Background 

The  concept  of  a  common  desktop  environment  for  the  ESSM  Program  that 
permits  users  to  interact  with  other  program  participants  and  permits  users  to  access 
program  technical  data  and  documentation  is  a  stated  objective  of  the  Integrated  Logistics 
Support  (ILS)  Manager  for  the  ESSM  Program  Office.  It  is  thought  that  such  a  desktop 
environment,  with  common  software  applications  and  uniform  access  to  program  technical 
data  and  documentation  in  digital  formats,  will  foster  a  work  environment  that  is  superior 
to  one  where  program  responsibilities  are  carried  out  with  paper-based  processes. 

To  satisfy  this  requirement,  IDMS  was  proposed  by  PHD-NSWC  as  a  possible 
candidate  for  a  common  desktop  environment.  IDMS  had  the  advantages  of  being  an 
almost  fully  implemented  system.  It  had  demonstrated  functionality  in  CDRL  definition, 
tracking,  and  review.  It  also  could  operate  on  a  desktop  PC.  Some  of  IDMS’ 
shortcomings  included  its  heavy  dependence  on  the  proprietary  Interleaf  desktop 
publishing  application  and  its  associated  Printerleaf  and  Worldview  applications.  It  also 
lacked  a  true  workflow  manager  application. 

The  JCALS  system  should  be  considered  the  future  for  the  concept  of  a  technical 
data  management  system  with  a  common  desktop  environment.  Still  undergoing 
prototyping  and  development,  the  first  operational  systems  are  expected  to  be  delivered  in 
the  first  half  of  1996. 

In  January  of  1995,  IDMS  was  demonstrated  on  the  JCALS  prototype  site  at 
PHD-NSWC.  For  the  purposes  of  the  demonstration,  the  IDMS  icon  was  available  on  a 
JCALS  workstation  and  provided  access  to  the  IDMS  server  in  a  window  on  the  JCALS 
desktop.  An  IDMS  View  and  Edit  user  then  accessed  a  sample  document  and  assigned  it 
for  review  to  IDMS  Review  and  Comment  users  locally  at  PHD-NSWC  and  remotely  at 
the  Marine  Corps  Logistics  Base  (MCLB)  in  Albany,  GA.  The  IDMS  Routing  and  Mail 
systems  were  used.  The  Review  and  Comment  users  locally  and  at  MCLB  received 
notification  of  the  document  awaiting  review  by  E-Mail.  They  then  accessed  the  sample 
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document  and  made  their  comments  for  demonstration  purposes  using  editing  tools  locally 
available.  The  document  was  then  returned  to  PHD-NSWC  and  the  sample  comments 
were  incorporated  by  the  View  and  Edit  user  into  the  document.  Finally,  the  annotated 
sample  document  was  forwarded,  for  printing  using  JCALS,  to  the  Defense  Printing 
Service  which  is  co-located  with  PHD-NSWC  at  the  Naval  Construction  Battalion  Station 
in  Port  Hueneme,  CA.  This  comprehensive  demonstration  proved  that  a  legacy  system, 
like  IDMS,  albeit  only  a  couple  of  years  old,  could  coexist  with  a  newer  information 
system  such  as  JCALS. 

2.  Implementation  Plan 

Presently,  the  Information  Technology  Department  at  PHD-NSWC  has  initiated  an 
integration  effort  to  incorporate  portions  of  JCALS  into  IDMS.  PHD-NSWC  intends  to 
purchase  the  GOTS  portions  of  JCALS,  namely  the  Workflow  Manager  application, 
Global  Data  Base  Manager,  and  Reference  Library.  CSC  will  provide  integration  support 
to  PHD-NSWC  on  a  fee  basis  as  condition  of  the  sale  of  the  GOTS  portions  of  JCALS. 
SAIC  will  perform  the  integration  effort,  with  a  projected  completion  data  of  the  latter 
half  of  1995. 

The  most  significant  objective  of  the  implementation  plan  is  for  the  Interleaf 
desktop  publishing  application,  and  its  associated  Worldview  and  Printerleaf  applications, 
to  be  useable  with  JCALS’  reference  library,  workfolder,  and  Workflow  Manager 
application.  IDMS  and  its  associated  CDRL  definition,  tracking,  and  review  functions  are 
a  significant  portion  of  the  ISEA’s  responsibilities  during  a  weapon  system  program  and 
are  currently  only  implemented  in  Interleaf  5.  The  plan  to  integrate  JCAL’s  Workflow 
Manager  into  IDMS  will  provide  IDMS  View  and  Edit  users  the  ability  to  perform 
Business  Process  Reengineering  on  current  procedures.  This  may  lead  to  the  creation  of 
workflows  for  the  various  types  of  processes  expected  to  be  performed  by  the  ISEA 
during  the  ESSM  contract. 

PHD-NSWC  fully  expects  to  migrate  from  IDMS  to  JCALS  during  the  life  of  the 
ESSM  contract.  It  is  hoped  that  this  intermediate  step  of  integrating  portions  of  JCALS 
with  IDMS  will  ease  PHD-NSWC’s  and  other  ESSM  Program  participant’s  transition  to 
full  JCALS  in  the  future. 

This  chapter  has  presented  the  Integrated  Data  Management  System  (IDMS),  an 
information  system  that  allows  users  to  access  and  process  many  types  of  technical  data  on 
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integrated  technical  databases  from  a  common  computer  desktop  environment.  IDMS’ 
strengths  are  its  open  client-server  architecture,  its  integration  with  COTS  applications, 
and  its  functionality  in  defining,  tracking  and  reviewing  CDRL  data.  These  factors  make 
IDMS  a  suitable  candidate  for  integration  with  a  system  like  JCALS  that  does  not 
presently  have  the  full  functionality  that  is  required  at  the  awarding  of  the  ESSM  contract. 
Fortunately,  IDMS  has  a  generic  enough  nomenclature  that  allows  it  to  endure  as  an 
information  system  that  metamorphoses  into  a  more  capable  integrated  system. 

The  next  chapter  presents  the  conclusions,  recommendations,  and  issues  for  further 
research. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


This  chapter  presents  some  answers  to  the  research  questions  addressed  by  this 
thesis  and  discusses  several  issues  raised  during  the  investigation  that  may  warrant  further 
research.  The  chapter  concludes  with  specific  recommendations  related  to  the 
management  of  technical  data  for  the  ESSM  program. 

A.  APPLICATION  OF  THE  CALS  INITIATIVE  TO  THE  ESSM  EMD 

PHASE  CONTRACT 

This  section  describes  how  the  ESSM  program  office  should  continue  to  evaluate 
the  applicability  of  the  CALS  initiative  and  especially  its  data  format  specifications  to  the 
ESSM  EMD  phase  contract. 

1.  Conclusions 

Given  the  recent  changes  in  DoD  acquisition  policies  that  were  brought  on  by 
Secretary  of  Defense,  William  J.  Perry’s  memorandum,  “Specifications  &  Standards  -  A 
New  Way  of  Doing  Business,”  the  ESSM  PM  released  the  ESSM  EMD  phase  contract 
RFP  in  a  turbulent  defense  acquisition  environment.  It  should  be  noted  that  the  DoN, 
NAVSEA,  and  the  ESSM  program  office  certainly  had  their  fingers  on  the  pulse  of  the 
coming  acquisition  reforms.  This  was  evidenced  by  the  usage  of  the  Navy  Standards 
Improvement  Program  during  the  ESSM  acquisition  planning  process.  To  summarize 
fi-om  the  material  presented  in  Chapter  IV,  the  ESSM  program  office  evaluated  over  100 
specifications  and  standards  applicable  to  the  ESSM  program  and  deleted  23  military 
specifications  and  standards,  substituted  31  commercial  standards,  and  used  43  military 
specifications  and  standards  including  eight  CALS  military  specifications  and  standards. 
Without  question,  the  ESSM  program  office  was  out  in  front  of  the  coming  wave  of 
acquisition  reform. 

Although  release  of  the  ESSM  EMD  phase  contract  RFP  fell  within  the  180  day 
“grace  period”  offered  by  the  Perry  memorandum  for  ongoing  solicitations  and  contract 
negotiations,  the  ESSM  program  office  sought  to  evaluate  the  application  of  the  CALS 
initiative  military  specifications  and  standards.  Subtle  changes  in  wording  and  the  request 
of  a  two-year  waiver  for  two  of  the  CALS  standards  relating  to  Logistic  Support  Analysis 
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Records  (LSARs)  indicate  the  ESSM  PM’s  willingness  to  comply  with  the  spirit  of  the 
new  acquisition  policies  called  for  in  Secretary  Perry’s  memorandum. 

This  research  concludes  that  the  ESSM  program  office  should  continue  to  monitor 
the  applicability  of  the  CALS  initiative  and  its  military  specifications  and  standards  in  the 
current  defense  acquisition  environment.  Even  though  these  CALS  military  specifications 
were  applied  to  the  EMD  phase  RFP  and  will  likely  be  “called-out”  in  the  contract  award, 
they  should  continue  to  be  evaluated  by  the  ESSM  program  office  for  their  applicability 
given  the  recent  acquisition  reforms.  Until  the  DoD  CALS  &  EDI  Policy  Office  resolves 
how  the  CALS  initiative  will  continue  to  exist  given  the  current  DoD  acquisition 
environment,  the  ESSM  PM  should  be  prepared  to  reissue  and  possibly  modify  the  EMD 
phase  contract  RFP  if  it  deems  that  this  is  a  prudent  course  of  action. 

This  position  is  especially  true  when  considering  the  CALS  data  format 
specifications  that  were  presented  in  Chapter  III.  DoN  activities  participating  in  the 
ESSM  program  are  unfamiliar  with  handling  technical  data  in  CALS -compliant  formats 
such  as  SGML.  Specification  of  contractor-delivered  textual  data  in  SGML  will  only 
present  new  challenges  for  the  DoN  activities  that  are  responsible  for  reviewing  and 
commenting  on  the  technical  data. 

2.  Issues  for  Further  Research 

This  investigation  determined  that  the  changes  in  acquisition  policies  called  for  in 
Secretary  Perry’s  memorandum  placed  an  enormous  burden  on  acquisition  managers  to 
seek  performance  or  commercial  standards  that  were  equivalent  to  military  specifications 
and  standards.  With  this  policy  change,  acquisition  managers  must  not  only  be  familiar 
with  current  military  specifications  and  standards  and  how  they  are  applied  to  a  defense 
system  procurements.  Now,  time  consuming  and  manpower  intensive  investigations  into 
industry  practices  and  non-government  standards  must  also  be  completed  during  the 
acquisition  planning  process.  Further  study  in  this  area  should  be  directed  at  developing 
some  type  of  evaluation  framework  or  methodology  for  comparing  current  military 
specifications  and  standards  to  performance,  commercial,  or  non-government  standards. 
Without  such  an  evaluation  framework  or  methodology,  the  alternative  will  be  an  longer 
acquisition  time  lines. 
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B.  EVFORMATION  TECHNOLOGY  INFRASTRUCTURE  AT  THE  IN- 

SERVICE  SUPPORT  ENGINEERING  AGENT 

This  section  presents  conclusions  on  several  issues  that  have  an  impact  on  the 
Navy’s  surface  ship  weapon  system  In-service  Support  Engineering  Agent’s  (ISEA)  ability 
to  perform  its  mission.  Several  issues  that  this  investigation  determined  warranted  further 
research  are  also  presented. 

1.  Conclusions 

The  ISEA  is  the  one  Navy  activity  that  has  to  “live”  with  the  decision  specifying 
what  format  technical  data  for  a  weapon  system  is  delivered  by  a  contractor.  It  is  not  an 
overstatement  to  assert  that  the  effectiveness  of  the  ISEA  hinges  on  a  decision  specifying 
the  format  of  the  contractor-delivered  technical  data  made  during  the  acquisition  planning 
process.  In  a  budget  climate  where  declining  resources  are  the  norm,  it  is  unlikely  that  the 
funding  to  accomplish  a  conversion  of  technical  data  from  a  legacy  format  to  a  more 
useable  format  will  ever  be  available.  Such  efforts,  if  necessary,  will  need  to  be  funded 
from  the  I  SEA’S  operating  funds.  This  situation  makes  the  specification  of  technical  data 
formats  even  a  more  important  process  during  acquisition  planning. 

The  information  technology  (IT)  infrastructure  at  the  Navy’s  weapon  system 
ISEA  can  and  should  have  an  impact  on  how  an  acquisition  manager  specifies  the  delivery 
weapon  system  technical  data.  Currently  the  IT  infrastructure  at  Port  Hueneme  Division, 
Naval  Surface  Warfare  Center  (PHD-NSWC)  is  a  heterogeneous  hardware  and  software 
environment.  It  reflects  the  diversity  of  the  various  types  of  technical  data  specified 
during  a  weapon  system  program’s  life-cycle.  Development  of  information  systems,  such 
as  the  Integrated  Data  Management  System  (IDMS),  indicate  the  desire  of  PHD-NSWC 
to  standardize  on  an  open  architecture  for  computer  workstations,  PCs,  commercially 
available  software  operating  systems  (UNIX  and  X-Windows),  and  applications.  While 
this  strategy  is  admirable,  it  has  not  positioned  PHD-NSWC  to  capitalize  on  the  Navy’s 
efforts  to  specify  delivery  of  technical  data  in  CALS-compliant  data  formats,  especially 
SGML.  PHD-NSWC’s  current  effort  to  integrate  IDMS  with  the  government-owned 
software  applications  of  JCALS  is  exactly  the  right  course  of  action  to  follow.  This 
should  ease  PHD-NSWC’s  transition  to  the  overall  JCALS  infrastructure  and  application 
suite. 
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One  of  PHD-NSWC’s  major  IT  infrastructure  shortcomings  identified  during  this 
research,  is  its  lack  of  a  comprehensive  enterprise-wide  network  architecture.  Networking 
information  systems  with  client-server  architectures  using  Thick  Ethernet  cabling  limits  an 
information  system’s  potential  and  places  a  ceiling  on  the  types  of  data  that  may  be 
processed  at  a  user  desktop.  As  technical  documentation  such  as  technical  manuals  evolve 
to  Interactive  Electronic  Technical  Manuals  (lETMs),  the  existing  network  architecture 
■will  not  support  such  resource  intensive  requirements.  lETMs  contain  drawings,  graphics, 
and  multimedia  features  that  are  interactively  linked  and  ivill  require  high  data  transfer 
rates  to  the  technical  writer’s  client  application  from  hypermedia  servers.  Additionally  the 
existing  network  architecture  makes  it  difficult  to  institute  the  processing  of  classified 
technical  data  and  business-sensitive  documentation.  One  alternative  is  to  consider 
subdividing  the  existing  network  into  sub-nets  that  serve  functional  processes  within  PHD- 
NSWC. 


2.  Issues  for  Further  Research 

The  most  pressing  issue  for  further  research  related  to  PHD-NSWC’s  IT 
infrastructure  is  its  lack  of  an  enterprise-wide  network  architecture.  Clearly  a  significant 
effort  must  be  made  to  design  a  network  architecture  that  will  support  the  requirements  of 
PHD-NSWC.  The  second  issue  requiring  further  research  is  the  development  of 
workflows  that  reflect  the  ISEA’s  functional  processes  being  carried  out  with  digital 
technical  data  formats  instead  of  paper-based  formats.  Once  the  modeling  of  workflows 
has  been  accomplished,  they  should  be  created  on  JCALS’  workflow  manager  application 
and  tested  if  possible.  Once  the  integration  of  IDMS  and  JCALS  is  complete,  it  should 
facilitate  the  transition  to  accomplishing  ISEA  responsibilities  entirely  with  digital 
technical  data  formats. 

C.  DATA  MANAGEMENT  PLAN  FOR  THE  ESSM  PROGRAM 

This  section  points  out  several  criticisms  of  the  Data  Management  Plan  (DMP)  for 
the  ESSM  program  as  it  stands  in  its  current  draft  form.  Specific  recommendations  on 
how  the  DMP  could  be  improved  to  better  reflect  how  the  Government  intends  to  manage 
technical  data  are  also  presented. 
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1. 


Conclusions 


The  Data  Management  Plan  (DMP)  as  it  stands  in  its  current  draft  form  is  too 
specific  in  some  areas  and  very  general  in  other  areas  of  technical  data  management.  For 
example,  the  DMP  focuses  on  the  use  of  the  Integrated  Data  Management  System 
(EDMS)  to  such  a  degree  that  it  explicitly  describes  the  functionality  of  the  system. 
However,  the  DMP  does  not  address  core  technical  data  management  tasks.  One  such 
task  is  how  ESSM  documentation  will  be  controlled  by  the  ESSM  Data  Manager.  For 
instance,  there  is  no  discussion  in  the  DMP  of  a  document  version  numbering  scheme. 
Additionally,  the  DMP  in  its  current  form  does  not  address  the  exchange  of  classified 
technical  data  and  business-sensitive  ESSM  documentation.  Although  it  asserts  that 
IDMS  must  be  capable  of  transmitting  and  receiving  classified  technical  data  such  as 
engineering  drawings,  specific  security  procedures  have  yet  to  be  developed. 

2.  Recommendations 

The  core  recommendations  that  this  research  makes  are  directed  at  how  the  Data 
Management  Plan  could  be  improved  to  reflect  issues  relating  to  the  management  of 
technical  data.  The  draft  Data  Management  Plan  is  an  annex  to  the  Master  Program  Plan 
(MAPP)  which  is  expected  to  be  completed  by  mid- 1995.  At  that  time  the  entire  MAPP 
will  be  presented  to  the  ESSM  prime  contractor.  The  draft  Data  Management  Plan  at  the 
time  of  this  writing  was  being  reviewed  and  commented  on  by  each  of  the  Navy  activities 
participating  in  the  ESSM  Program.  It  is  a  plausible  conclusion  that  many  of  the  issues 
presented  below  may  already  have  been  incorporated  in  the  final  version  of  the  DMP. 
This  investigation,  because  of  time  constraints,  did  not  have  access  to  the  preliminaiy 
comments. 

The  remainder  of  this  section  presents  recommendations  on  issues  that  a  DMP 
should  address  to  fiilly  describe  to  the  contractor  how  the  Government  intends  to  manage 
technical  data. 


a.  Technical  Data  Working  Group 

First,  it  is  recommended  that  the  ESSM  PM  establish  a  Technical  Data 
Working  Group  that  meets  regularly  to  discuss  technical  data  matters.  Membership  in  the 
group  should  include  representatives  from  technical,  logistic,  program  management,  and 
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information  technology  management  fields.  The  Technical  Data  Working  Group  would  be 
responsible  for  identification  of  technical  data  types,  processes,  and  management  systems. 
Each  of  these  responsibilities  is  described  below. 

b.  Identification  of  Technical  Data  Types 

One  of  the  first  responsibilities  of  the  Technical  Data  Working  Group  is  to 
identify  the  various  technical  data  types  that  will  be  used  during  the  life-cycle  of  the 
weapon  system.  This  begins  with  the  determination  of  what  legacy  technical  data  exists 
and  whether  it  will  be  used  for  the  new  weapon  system.  At  this  time,  a  decision  must  be 
made  on  whether  to  retain  the  legacy  technical  data  in  its  current  format  or  to  convert  it  to 
a  different  format  that  takes  advantage  of  current  technology.  An  issue  for  consideration 
is  how  the  new  technical  data  will  be  identified  if  legacy  data  is  used  to  generate  new 
technical  data?  For  instance,  if  a  legacy  engineering  drawing  is  used  as  a  starting  point  to 
create  a  new  drawing  for  a  weapon  system,  at  what  point  is  the  new  drawing  considered  a 
whole  new  drawing  rather  simply  a  modification  of  the  legacy  drawing? 

The  Technical  Data  Working  Group  is  also  responsible  for  identifying  what 
technical  data  types  will  be  generated  by  the  contractor.  Ideally  this  responsibility  is  acted 
upon  very  early  in  the  acquisition  planning  process,  since  it  would  constitute  an  input  to 
the  weapon  system  contract  SoW  and  the  generation  of  CDRLs.  This  responsibility 
requires  complete  familiarization  of  the  CALS  initiative  military  specifications  and 
standards.  Since  the  Secretary  of  Defense  memorandum  now  directs  that  the  CALS 
military  specifications  and  standards  be  viewed  as  guidance  by  acquisition  managers,  this 
requires  that  working  group  members  investigate  performance,  commercial,  and  non¬ 
government  standards  that  yield  technical  data  or  processes  that  are  equivalent  to  what  the 
CALS  military  specifications  and  standards  would  have  )delded. 

c.  Identification  and  Description  of  Technical  Data  Processes 

Once  the  Technical  Data  Working  Group  identifies  the  technical  data  types, 
each  of  the  necessary  technical  data  processes  should  be  identified  and  described.  The 
perspective  for  identifying  these  technical  data  processes  should  be  from  the  program 
participant’s  responsibilities  during  management  of  the  weapon  system  contact.  The 
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description  of  how  the  technical  data  processes  should  be  carried  out  should  be  as 
complete  as  possible.  Below  is  a  recommended  list  of  sample  technical  data  processes; 

•  Data  Submission  is  the  process  by  which  technical  data  is  forwarded  to  the 
weapon  system  Data  Manager.  This  process  as  a  minimum  should  identify 
what  methods  and  which  protocols  are  to  be  used. 

•  Data  Access  and  Views  refer  to  how  the  Data  Manager  will  provide  access  to 
program  technical  data  to  other  program  participants.  This  process  should 
identify  how  classified  technical  data  and  business-sensitive  documentation  may 
be  accessed  and  viewed  by  program  participants.  It  should  include  what  rules 
are  in  effect  and  what  viewer  applications  will  be  used  for  technical  data  and 
program  documentation. 

•  Data  Routing  is  the  process  by  which  program  technical  data  will  be 
transferred  among  program  participants.  Transferring  of  technical  data  and 
program  documentation  refers  to  what  method  and  which  protocol  will  be  in 
effect.  It  includes  how  classified  technical  data  and  business-sensitive  program 
documentation  will  be  handled. 

•  Workflow  Generation  is  the  process  of  translating  current  acquisition 
processes  into  workflows  using  Business  Process  Reengineering  principles,  if 
this  has  not  already  been  done.  A  complete  detailing  of  who  will  be 
responsible  for  creating,  monitoring,  and  canceling  particular  classes  of 
workflows,  what  workflow  applications  vrill  be  used,  and  what  workflow 
conventions  will  be  followed  should  be  included. 

•  Data  Manipulation  and  Enhancement  refer  to  the  processes  by  which  technical 
data  and  program  documentation  is  altered  or  commented  upon.  This  process 
should  include  who  will  be  assigned  such  duties,  how  this  task  will  be  carried 
out,  and  what  application  will  be  used. 

•  Data  Ownership  and  Storage  will  be  the  overall  responsibility  of  the  program 
Data  Manager.  It  should  address  how  technical  data  will  be  controlled  (i.e. 
version  control)  and  how  it  will  be  stored  in  a  technical  data  repository. 

d.  Technical  Data  Management  Systems 

Technical  Data  Management  Systems  are  the  information  systems  that  are 
projected  to  be  used  during  the  life-cycle  of  the  weapon  system  program  to  handle 
technical  data  and  program  documentation  in  digital  formats.  This  section  should  not 
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explain  in  detail  how  the  data  management  systems  will  perform  the  necessary  technical 
data  processes.  Instead  it  should  address  how  the  system  will  be  administered  and  how 
the  system  will  be  deployed  among  program  participants.  The  types  of  information 
systems  can  be  categorized  into  legacy  systems,  CALS  infrastructure  modernization 
systems,  and  contractor  furnished  systems.  These  three  types  of  systems  are  explained 
below: 

•  Legacy  systems  are  information  systems  that  are  currently  in  use  or  under 
development  at  Navy  activities  participating  in  the  weapon  system  program. 
This  section  should  acknowledge  the  existence  of  these  systems  and  describe 
whether  they  are  compatible  with  the  program’s  needs.  Additionally,  migration 
options  to  the  CALS  infrastructure  modernization  systems  or  to  another 
information  system  should  be  discussed  here. 

•  CALS  infrastructure  modernization  systems  refer  to  the  Joint  Computer-aided 
Acquisition  and  Logistics  Support  (JCALS)  system  and  the  Joint  Engineering 
Drawing  Management  Information  Control  System  (JEDMICS).  This  section 
should  address  whether  either  of  these  systems  are  available  for  program 
participants  or  how  program  participants  may  eventually  migrate  their  technical 
data  and  processes  to  these  systems. 

•  Contractor  furnished  systems  refer  to  either  the  CALS  military  specification  for 
a  Contractor  Integrated  Technical  Information  Services  (CITIS)  system,  or  a 
proprietary  contractor  developed  system,  or  a  commercial  off-the-shelf  system 
if  available.  This  section  should  acknowledge  the  existence  of  these  types  of 
systems  and  describe  whether  they  are  compatible  with  the  program’s  needs. 

This  chapter  has  presented  conclusions  on  why  the  CALS  initiative  and  its 
data  format  specifications  should  be  reviewed  as  to  their  applicability  to  the  ESSM 
Engineering  and  Manufacturing  Development  phase  contract.  It  should  be  recognized  that 
a  tremendous  effort  by  ESSM  program  acquisition  managers  was  put  forth  to  developing 
and  issuing  the  EMD  phase  contract  RFP.  Clearly  these  individuals  were  faced  with 
challenging  issues  in  a  changing  DoD  acquisition  environment.  Application  of  the  CALS 
military  specifications  and  standards  to  this  weapon  system  acquisition  was  a  major  step  in 
the  acquisition  planning  process. 

Conclusions  on  why  the  Navy’s  weapon  system  ISEA  should  figure 
prominently  when  acquisition  planners  specify  contractor-delivered  technical  data  have 
also  been  presented.  Issues  requiring  further  research  including  the  ISEA’s  IT 
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infrastructure  especially  an  enterprise-wide  network  architecture  and  reengineering  of 
ISEA  technical  data  processes  have  been  described.  It  is  hoped  that  the  recommendations 
on  how  a  Data  Management  Plan  could  be  structured  will  be  helpful  to  acquisition 
managers  during  the  acquisition  planning  processes  for  fiiture  weapon  systems. 
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